GameConsole

Please note: This project is now continued by clwillingham and whoever else who can lend a hand.



I’m in the process of creating a console system like most games have where you can enter commands instead of having to associate keyboard bindings to every debug action.  How much is there in me making this a general purpose extensible system so you can add your own arbitrary commands into it?  I don’t think I’m going to add this to jME but I will probably end up adding it to my game API I’m working on.



Has anyone else done anything like this before or any ideas about features?

I had the same vision. I almost tried this a few months back. How are thinking about implementing this? Maybe Fengui?

At the moment I'm just using bitmapped text (like what the FPS display is). This maintains better performance probably than any alternative.  It doesn't look the prettiest, but when you're using a console I would expect you should care more about functionality and performance than "pretty". :wink:

Okay, I've got the following features so far:


  • Ability to add ConsoleCommand interface implementations for completely extensible console system with variable params space separated or using quotes to encapsulate

  • GameConsole is a GameState that shows nothing by default until you press the "activation key" to toggle it visible or invisible

  • Allows you to define how many rows are visible (how many lines of text to show when displaying the console)

  • Allows enabling or disabling of echoing commands

  • Provides functionality for standard keyboard characters, displays a cursor, allows moving left, right, home, end, and backspace while entering text

  • Use up and down arrows to navigate through the command history

  • Page Up and Page Down to scroll through console history. Locks position while displaying history and unlocks when at the bottom of entries

  • Allows programmatic interaction to invoke any command inside console screen

  • Assign a maximum entries for command history and console history. These both default to 100 entries.



I still have to finish some integration of basic commands and command parsing, provide slide-in effect when opening console, background image support, and a few other niceties but it's working extremely well and extremely fast. :)

Okay, here’s a direct link to the source code for anyone interested in giving constructive criticism or just to laugh at me for taking all this time to re-invent a console.  :stuck_out_tongue:



http://captiveimagination.com/svn/public/cigame/trunk/src/com/captiveimagination/game/console/GameConsole.java

http://captiveimagination.com/svn/public/cigame/trunk/src/com/captiveimagination/game/console/command/ConsoleCommand.java

http://captiveimagination.com/svn/public/cigame/trunk/src/com/captiveimagination/game/console/command/ExitStandardGameCommand.java

http://captiveimagination.com/svn/public/cigame/trunk/test/test/TestConsole.java



If you want to test it you’ll need to remember to hit the ‘`’ key to make it pull up because it’s invisible by default.  There’s only one very basic command there now, but it’s time for bed and I still have other stuff to do.  :’(

Sounds good :slight_smile: Reinventing the console is good, especially if it ends up being light and fast. I was thinking of doing at least the text bits of something like that myself, for displaying messages during missions ("Go to Nav point 1 and destroy the carrier" etc.).



On the background image support thing, http://www.jmonkeyengine.com/jmeforum/index.php?topic=4745.0 might be useful, if you want a panel with corners and edges instead of just a simple Quad background. I actually made it for the text display thing, I just got sidetracked into doing sound before I got to the actual text :slight_smile: If you use the DialogBox with a 32x32 image containing a 30x30 panel with a 1 pixel border around it, it will stretch the edges and middle to give you whatever width and height you need. For example, you can just use an alpha texture with a rounded edged box (the rounded edged corners need to fit in the 10x10 corners of the 30x30 center of the image). There should be plenty of images designed for web pages etc. that you could use. You can use it just to get rounded edges, or an RPG style fancy border, or drop shadows, etc.

i like it. license?

There currently is no license due to the neglect of shingoki.  :stuck_out_tongue:



I believe he said he wanted LGPL?

Thats cool. Thanks alot darkfrog. One thing I noticed, when the console is not showing it will still pickup the key strokes like your typing them in. Have you got it setup to not listen when you dont want it to?

Oops…that's a mistake.  I'll get that corrected tonight hopefully.  Thanks. :slight_smile:

Very cool darkfrog!!



I was thinking of putting together a console to do things like load scripts at runtime, or perhaps to allow users to enter scripts on the console. I can absolutely use this as starting point. Why wouldn't this be added to the jME source code or at least the jmex package? I think along with things like GameState a Console, or at least an idea of an integrated command system (activated based on multiple types of triggers, key bindings, GUI events, console commands, etc.)



For the script console I was thinking of something like:



eval < Box b = new Box("test", …)



>



Then the string with the eval <…> would be run during the update() of the game, to attach new items to the scene etc. Although it'd be more practical to create a high level API that could then be scripted with objects and scene elements easily managed in script code.

Well, this isn't finished yet, so before you go extending it wait and see what all I have in store for it. :wink:



As for adding it to jME I don't have a problem doing so if the other devs agree that this would be a useful feature?  I'm just trying to cut down on the extra junk in jME.

Sounds good, I'll keep up to date with the SVN for that code, let me know when you think it's semi stable (as in no foreseeable interface changes to the Command interface), I still have to work on the general scripting framework separately anyways.



I think the Console fits within the jME project, although if it doesn't maybe there should be another jME extensions project made kind of like Apache commons, where a bunch of common game utility code can be collected and inserted into games by piece-meal instead of having a huge hulking library containing everything including things you don't need for your particular game. jME already includes separate jars which accomplishes this to a point.

maybe there should be another jME extensions project made kind of like Apache commons, where a bunch of common game utility code can be collected


I think that would be jme-contrib. :D
http://www.jmonkeyengine.com/jmeforum/index.php?topic=4640.0

Cool, I think I stumbled across that before.



So right now it looks like the jme-contrib project contains an MD5 loader and a Cal3d loader.



How active is this project? It appears that kman is running it, and the last activity that I can tell is about 6 months ago.



I'm thinking of writing up some jME tutorials and a script framework, and an AI tutorial soon, maybe I'll request being added to that project and publish that stuff there.

Well, like the referenced thread states, I've decided to go ahead and create my own API extension so I can use Subversion and everything else on my server.



This is where the code is being kept currently.  If other devs express an interest in having this be part of jME I will move it.

I'm neglectful!



Yup LGPL would be good :slight_smile:



I must give it a go, I haven't had a chance yet, just finished work.



[Edit] I had a look, looks really nice :slight_smile: I'm gonna try that background thing, and maybe try some commands in my game. Actually this is a good incentive finally to move to game states :slight_smile:



I also noticed while digging around to work out how to set the size of a background panel, that fonts are currently fixed size in jme, 10x16. That's a fairly reasonable size, but I was wondering whether some kind of method of getting/setting font sizes in pixels would be good to have now, to allow for stuff like the console to take account of different sizes that might crop up in future.

dougnukem said:

I was thinking of putting together a console to do things like load scripts at runtime, or perhaps to allow users to enter scripts on the console.

<snip>

For the script console I was thinking of something like:

eval < Box b = new Box("test", ....)
...
>

Then the string with the eval <....> would be run during the update() of the game, to attach new items to the scene etc. Although it'd be more practical to create a high level API that could then be scripted with objects and scene elements easily managed in script code.


So Darkfrog can add Java 1.5+ script engine integration?  }:-@  I've never used it but am wonder if you could also security-limit the objects available for end-users, and also if it would be useful as a higher level scripting front end to JME for torque-esq development. Makes me want to screw around with adding a scripting interface to MonkeyWorld3D...


Adding scripting to MonkeyWorld3D would be awesome!!



I'd be willing to help out if you want to bounce any ideas around.



I started some stubs on my developer wiki for a jME script framework (using Java 6).

http://eventhorizongames.com/wiki/doku.php?id=articles:jmonkey_engine_scripting



Based on some of the scripting articles I've read:

http://eventhorizongames.com/wiki/doku.php?id=articles:java_scripting_framework



It'd be cool if you could right click an object you created in MonkeyWorld3D RCP and attach a script controller, or setup a conditional event that would trigger a script (or a whole slew of script hooks for event handler, onCollide(), onActivated(), or custom events triggered from other objects in the world).



I was wondering if there were any plans to take MonkeyWorld3D and add plugins into it, so that specific games could tailor it to provide building blocks for their specific game. (FPS, action, 2.5D side scroller, etc). I'd be willing to help out with that if I can also.

shingoki said:

Yup LGPL would be good :)

BSD would be better - e.g. because it's compatible with jME's license :P