Sign in to follow this  

FPS style console?

This topic is 4780 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

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?

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites

User (presses keys)

|
v

Simple 'dumb terminal' I/O (Shows input/output text)

|
v

Command parser (Converts strings into 'tokens')

|
v

Code to do it (execute token commands)

Share this post


Link to post
Share on other sites
The console I have for my engine uses bitstreams to store command data. I use the bitstream class from Raknet. You load command files into the console, which contain command prompts like

move_viewport
scene_mngr
moves_a_viewport_relative_to_its_current_position
4
name
scene
delta_x
delta_y

So you type in the command "move viewport" and you get prompted for the name, scene, and change in x/y in that order (the third line is help text). This is the basic command structure, which lets me create any command with any number of parameters. Each prompt is stored in the bitstream, and then the bitstream is sent via the message system to the specified object, in this case "scene mngr". Then it's the job of "scene mngr" to receive the message, extract the data from the bitstream and handle it accordingly.

So in this way, any game object I create can receive a console command, the console is decoupled from the engine in that it doesn't have to know what its commands do, and it can take any sort of command I want it to.

I've been thinking about writing this up as an article when I find the time.

Share this post


Link to post
Share on other sites

This topic is 4780 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this