Archived

This topic is now archived and is closed to further replies.

Quake like console design question

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

Recommended Posts

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

Share on other sites
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.

bpopp (bpopp.net)

Share on other sites
In my opinion, this looks unintuitive, unclear, annoying and harder to manage.

If you want categories, I find it better to just use postfix names, like Quake 3.

con_clear
con_cmdlist
con_varlist
eng_dedicated
eng_quit
eng_restart
map_flush
map_timelimit
net_rate
net_name
net_hostname
net_connect
net_reconnect
net_disconnect
snd_effectvol
snd_musicvol
snd_restart
vid_mode
vid_colordepth
vid_fullscreen
vid_restart

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.

Share on other sites
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

Share on other sites
quote:
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.

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.

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

Interesting. I''m working on something very similar for parsing network messages. I wrote a question about it yesterday and got some interesting comments (a couple anyway).

bpopp (bpopp.net)

Share on other sites
quote:

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

Share on other sites
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

Share on other sites
This is similiar to what bf1942 does, assuming you don''t actually mean you can "change directories" forcing you to back out of graphics should you wish to get to sound - that''d be asinine.

[My site|SGI STL|Bjarne FAQ|C++ FAQ Lite|MSDN|Jargon]
Ripped off from various people

Share on other sites
If you did autocomplete, it could be nice to arrange the commands in a heierarchial tree. For example you type "Con." and a menu pops up with all the commands controling the console, things like "Speed", "Color", "TextColor", etc. It would be just like in quake where you type "con_", just that it looks a little more familiar to programmers and has a nice popup menu =-)
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), "Graphics" ("Gfx."), etc. Its really only good for those that don''t know the commands well, but can remeber what it effects. Want to increase texture brightness? pick gfx, then tex, then brightness

Share on other sites
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

• 9
• 13
• 40
• 15
• 11