Jump to content
  • Advertisement
Sign in to follow this  
KulSeran

FPS style console?

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

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
Something to think about: my console is just a "chat" object which has its input bound to "consoleinput" rather than "chatinput".

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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!