FPS style console?
Author
First off, i'd like to see some links to a good tutorial on this.
Second, after looking at the CodeOnTheCob from this site, I would
like to know what kind of distinctions you would make between
a console, an event system, and a scripting system.
The console seems to have aspects of both a script running rutine
and a way to trigger events. So is there a reason to use the
console rutines within the program? or would that be slower than
writing a seperate event manager? Is the sole reason for the
console to provide a way for the user to get feedback/change
the gamestate while it is running?
IMO the console itself should be decoupled from the other systems you described, if possible. The console is basically a system for displaying information and receiving input. What you do with that input is another issue, and should be handled by other modules. For example, in my system when the user enters a line of text, it's dispatched to another system which parses it and takes the appropriate action (execute command, change variable state, chat, etc.).
There's a tutorial somewhere on flipcode about console commands and variables that might be of some interest to you. Although it's a work in progress, I'm pretty happy with my system, so if you have any more specific questions just ask.
There's a tutorial somewhere on flipcode about console commands and variables that might be of some interest to you. Although it's a work in progress, I'm pretty happy with my system, so if you have any more specific questions just ask.
A console system ala quake is just an array of strings.
When you render the strings they move up as you add more of them.
Its something a totally seperate system from the rest of your game.
When you render the strings they move up as you add more of them.
Its something a totally seperate system from the rest of your game.
Author
try_catch_this i beg to differ, that is what you see, not what is happening in a console...
JYK. thanks for the input.
I still wonder though, how are commands like
"spawn monster_bob at ( 1,2,3 ) with {health=100;}"
would be handled, since spawn events will happen via
some ingame functions/game scripts. And it would be nice
to have the console accept commands that look just like scripts.
So what exactly are the benifits of seperating the systems vs.
integrating them all so that it fits a structure like:
console -> script engine -> event system -> gamestate DFA
JYK. thanks for the input.
I still wonder though, how are commands like
"spawn monster_bob at ( 1,2,3 ) with {health=100;}"
would be handled, since spawn events will happen via
some ingame functions/game scripts. And it would be nice
to have the console accept commands that look just like scripts.
So what exactly are the benifits of seperating the systems vs.
integrating them all so that it fits a structure like:
console -> script engine -> event system -> gamestate DFA
They occur the same way the scripting language occurs -- compiled into bytecode then run.
Any other commands have very specific parameter types and bounds, and any errors simply negate the statement.
Any other commands have very specific parameter types and bounds, and any errors simply negate the statement.
As far as separating the systems goes, I just think it makes for more modular, reusable code. Conceptually, a scripting or command parsing system doesn't really have anything to do with a console, aside from the fact that the console receives the input and displays the results.
Or, here's an example. One of the things you often want to do with a command parsing system is execute a config file at game startup that contains default settings, key bindings, etc. In my system there's a module dedicated to command parsing and dispatching, and it takes responsibility for executing the config file. Again, it really doesn't make much sense for a console to execute a config file - that's really not its job. Its job is simply to recieve input and display output.
But that's just my design philosophy - there are certainly other ways of doing it.
As far as the console accepting script-like commands, that's up to you. If you have a script parser which can parse and execute any string, whether it be from a file or elsewhere, then you can just send the input from the console to the script parser whenever the user flushes the command line.
In the Quake console, things like your example are generally handled by a command with multiple arguments. So you would type:
]/spawn_monster 1 2 3 100
An implementation that supported scripts would certainly be more flexible, though.
Or, here's an example. One of the things you often want to do with a command parsing system is execute a config file at game startup that contains default settings, key bindings, etc. In my system there's a module dedicated to command parsing and dispatching, and it takes responsibility for executing the config file. Again, it really doesn't make much sense for a console to execute a config file - that's really not its job. Its job is simply to recieve input and display output.
But that's just my design philosophy - there are certainly other ways of doing it.
As far as the console accepting script-like commands, that's up to you. If you have a script parser which can parse and execute any string, whether it be from a file or elsewhere, then you can just send the input from the console to the script parser whenever the user flushes the command line.
In the Quake console, things like your example are generally handled by a command with multiple arguments. So you would type:
]/spawn_monster 1 2 3 100
An implementation that supported scripts would certainly be more flexible, though.
You should separate systems unless it simply doesn't make sense. For a console, it's just text based input and output; in my opinion for a system-level user. If it's enabled, display it and have keystrokes sent to it instead of the game engine. Once the command line is sent, parse the command and execute it if that's appropriate, or send the command to whatever system is responsible for that type of command.
Author
Ok. This is all starting to make more sense.
Thanks for the input.
Looks like i need to make a console that can register handler
functions. Then gather input, and send it off to a handler.
If any output is recieved place it in a buffer for later rendering.
Thanks for the input.
Looks like i need to make a console that can register handler
functions. Then gather input, and send it off to a handler.
If any output is recieved place it in a buffer for later rendering.
Something to think about: my console is just a "chat" object which has its input bound to "consoleinput" rather than "chatinput".
Personally, I would implement a console exactly as try_catch_this stated. It would merely be an input/ouput device, and it would not handle any kind of parsing or scripting or events itself. It would just pass the input to another system that turned the text into meaningful actions, probably something like an 'Eval' function built into the already-in-place scripting system.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
