Patch 682 - Input+Unit+Fix

Jan 12, 2008 at 7:30 PM
This is a new version of the changes for patch 675, heres what I've changed:
  • MouseHandler will now release the mouse cursor if the game looses focus and reaquire it when it gets focus
  • It is now possible to select if you want to use the custom build or the standard cpc tool (see patch for details)
  • It also contains LordIkons camera time update fix

Any comments?
Jan 13, 2008 at 4:00 AM
Looks great! Sorry I didn't have time to check it out until now. Schools back in session so I have a lot less time than I had over break. :(

The only oddity I found was that when the game starts, the mouse controls the camera. When I click the right mouse button, I lose camera control and only regain control when I hold the right mouse button. I assume having to hold the right mouse button is intentional, but is the program supposed to start as if the right mouse button was being held until I actually click it?

Profiling shows minimal garbage. Over a 20 second run of mostly mouse panning, the MouseHandler::UpdateCore method generated 400 kb of garbage. That's well within the acceptable range, especially for the Windows generational collector.

I tried to find coding guideline violations, but I knew it was a futile attempt from the start. :)
Jan 13, 2008 at 8:03 AM
Edited Jan 13, 2008 at 1:12 PM
I've changed the behavior so that the game now always has mouse move enabled and rightclick is turbo boost (Movement speed x 4) :)

I've now fixed the issue with all message types being send on every frame so now you will only get the message type which was actually meant to be sent.

I've added a debug screen (that was easy) which shows message information, but I'm not too happy about the implementation of the screen functionallity, we most certainly need to rework of it in 0.20.
  • A reference to game is missing
  • It's not possible to disable/hide a screen
  • The positiion/size shouldn't be part of the constructor
  • It seems that the Compositor is a list/collection thingy, and should implement one of those interfaces, unifying the OM
  • The namespace seems odd as it mostly contains screens which is what most users will use

I've added a Aquire method to IPoolItem which is invoked when a item is aquired, this should be used to reinitialize an item. i also added a specific KeyMessage : Message<KeyData> which is used when sending messages, and KeyData which contains information about the key pressed and the modifier keys.

I'll try to check it in later today.
Coordinator
Jan 14, 2008 at 5:54 AM
Have we decided how we'd like to handle messages? I'd much rather have the gamepadhandler updates its info, and respond to queries, rather than send out a minimum of 14 messages per controller each frame.

Basically, is there a way for the gamepadhandler to listen in on messages in the way that FreeCamera.cs is right now? I might add that FreeCamera likely won't be able to do that down the road, as all messages for cameras will be handled by the CameraManager/CameraInterface.
Jan 14, 2008 at 6:19 AM
You can't have a general manager handle all messages, this would mean that the manager also would have to know about custom cameras and events, which is an impossible model.

Why do you need 14 messages? You should only send the changed states, and I don't believe that that will change every frame.
Coordinator
Jan 14, 2008 at 3:42 PM
I guess the messaging system is just backward from what I'm used to seeing. Normally the authority of the information, in this case, the gamepadhandler, controls and handles all information. However, in our case the handler would simply shoot out and change in the 14 or so states, and everything that used them would have to contain message handling.

What about the case when I want to fill a message with information, and have that information changed for me?

Like, I send a message with my X & Y mouse coordinates, and it fills that SAME message with the Vector3 world coordinates that the mouse is over.

Our system seems to imply we'd have to send a message, then handle another incoming message.
Jan 14, 2008 at 6:40 PM

LordIkon wrote:
I guess the messaging system is just backward from what I'm used to seeing. Normally the authority of the information, in this case, the gamepadhandler, controls and handles all information. However, in our case the handler would simply shoot out and change in the 14 or so states, and everything that used them would have to contain message handling.


I still can't see all those states, there has to be one for changingn the thumbsticks (or two if you wish), one for the thumbpapd and then 3 for buttons up/press/down so at max that gives: 14 messages per frame. But that's an very unlikely scenario. Though from a performace point of view that's nothing, sending 14 messages shouldn't take any processing (or rather very little), simply because there are going to be 100's if not 1000's of messages per loop.


LordIkon wrote:
What about the case when I want to fill a message with information, and have that information changed for me?


I don't understand the scenario, but if you send a message and there's going to be a response, then use should simply used SendMessage and the on GameMessage filter out the message you need.


LordIkon wrote:
Like, I send a message with my X & Y mouse coordinates, and it fills that SAME message with the Vector3 world coordinates that the mouse is over.


No not the same message the Type will be different, as the mouse type will be MouseMove vs ThumbstickMoved (or something), but most likely they will contain the same information


LordIkon wrote:
Our system seems to imply we'd have to send a message, then handle another incoming message.


If you need processing it yes, the Input system doesn't handle any incomming messages, it only sends messages, the network system will have to do both yes, and the FreeCamera only recieves messages. It's really up to the item in question as to what to do.
Coordinator
Jan 15, 2008 at 5:18 PM
Edited Jan 15, 2008 at 5:18 PM
Why send two messages where one could be sent.

For example, if I want a message that gives me mouse coordinates, and I want this message at ANY point in my code.

// sample function
public Vector3 get3DpointFromMouse()
{
      //pseudocode for messages not based off current message system
 
      // send message requesting mouse coordinates
      GetMouseCoordsMsg getMouseMsg;
      getMouseMsg.sendMessage();     // After this line executes, getMouseMsg will be filled with information
 
      MouseTo3DWorldPtMsg mouseMsg;
      mouseMsg.mouseX = getMouseMsg.mouseX;
      mouseMsg.mouseY = getMouseMsg.mouseY;
      mouseMsg.sendMessage();    // Send mouse coords, and the message is filled with the 3D world pt
      
      return mouseMsg.3DworldPt;
}

You can see how I send a message instantly, I can send info in that message, and the message goes to the destination, and uploads its info, and downloads any necessary info as well.

This allows instant information, rather than creating message handlers for everything needing feedback for messages. We also aren't required to wait even a single frame for instant messages. So we request info, get it, and use it immediately.
Jan 15, 2008 at 6:53 PM

LordIkon wrote:
Why send two messages where one could be sent.

For example, if I want a message that gives me mouse coordinates, and I want this message at ANY point in my code.

...

You can see how I send a message instantly, I can send info in that message, and the message goes to the destination, and uploads its info, and downloads any necessary info as well.

This allows instant information, rather than creating message handlers for everything needing feedback for messages. We also aren't required to wait even a single frame for instant messages. So we request info, get it, and use it immediately.


The system isn't build like that, it more similar to the winforms model. You can't actually ask the input system or the mouse handler about the current position as it doesn't know it. In fact the mouse is locked at 100,100 atm. Also asking the mouse/input about this makes not sense at that would mean that those systems would have to know something about the current coordinate system in use, which they cant. Instead the solution here would most likely be to have a cursor class which you would simply ask for it's possition, i.e.:

  // Here assuming that you are inside an entity
  this.Scene.Cursor.Position 

The cursor would most likely also send it's own game specific messages, such as CursorMove/CursorClick/CursorDblClick/etc.
Jan 15, 2008 at 7:02 PM
Don't forget that having a InputMapper would bridge this gap considerably. It would listen to the raw input messages, then client code can do queries on it directly based on input events. It could even allow for mouse/gamepad axes queries.
Jan 15, 2008 at 7:13 PM
It still wouldn't be able to tell you x,y position only relative movement. The mapper just maps events to client code. But in the bigger picture input is just a small subsystem, there might be other systems which would need that kind of information, but they would need to use a similar approach.
Coordinator
Jan 15, 2008 at 8:06 PM
Edited Jan 15, 2008 at 8:06 PM
Can you see the benefits to a messaging system like this? How much code will it take to do something similar with the current system? And, will it require waiting at least a frame to do so, plus making functions to handle all the messages I just used?

I should add that most of the message handling I keep referring to bases itself on the Unreal3 engine, and some other stuff....
Jan 15, 2008 at 8:17 PM
This is the first time I've seriously used a messaging system in a game, so I cannot speak from personal experience here, just from my intuition.

I can see the benefits of both systems. LordIkon, am I correct in assuming that your idea is to have fully synchronous messaging? For instance, if a piece of code sends a message, the message will be sent to all concerned end-points and responses will be collected before the send call returns? If so, how do you handle recursive cases, and messages going to multiple end-points? Are you restricted to one end-point per message type?

Further, where would GetMouseCoordsMsg and MouseTo3DWorldPtMsg be defined? Are these just generic engine-defined messages that the input system registers itself as the handler for?

Could you provide some more detail on how you would like the messaging system to work?

Besides possible dependency issues, the main issue I see is the following: system A sends a message to system B, but in order to respond, system B needs to send a message to system A. How would you handle or restrict that?

Like I've mentioned before, the 1-2 frame latency on messages does concern me, but at the same time we need to keep as abstract as possible.
Jan 15, 2008 at 10:40 PM

shawmishrak wrote:
I can see the benefits of both systems. LordIkon, am I correct in assuming that your idea is to have fully synchronous messaging? For instance, if a piece of code sends a message, the message will be sent to all concerned end-points and responses will be collected before the send call returns? If so, how do you handle recursive cases, and messages going to multiple end-points? Are you restricted to one end-point per message type?


The current system is sync, but there is no garentue that the messages are sent in any specific order. Since we are using eventing there is no garentue that the messages are invoked in a specific order. It's certainly possible to define endpoints using eventing as well, but it tends to get much more expensive than just letting the endpoints filter the messages.


shawmishrak wrote:
Further, where would GetMouseCoordsMsg and MouseTo3DWorldPtMsg be defined? Are these just generic engine-defined messages that the input system registers itself as the handler for?


This also concerns me, as there would have to be a method mer message, though using templated methods this might be a possible solution. Though I would have to see the different scenarios in order to really see this.


shawmishrak wrote:
Like I've mentioned before, the 1-2 frame latency on messages does concern me, but at the same time we need to keep as abstract as possible.


I might not have the knowledge to see the issue. All games have this issue somewhere. The update cycle is only executed once per cycle and only one per entity. Since we send the messages before we call update on the entities that delay shouldn't be noticeable, though I can certainly be wrong.
Coordinator
Jan 15, 2008 at 11:03 PM
The message is basically routed. Each manager/handler defines the messages it will handle, and then when you send the message, in that message you indicate which manager/handler you desire the message to go to.

You can specify the method in which you want to send a message. You can send it, requiring that is come back instantly, so that you can use its information immediately after you send it. Or, you can send the message to the queue and assume it will get done as soon as it gets the chance. If you send the message to a queue however you cannot immediately use the information that message will return, and your game logic cannot assume that whatever you wanted that message to do has already been done (at least not immediately).

If we are forced to have a frame or more of latency then the example I posted becomes impossible (at least in that format), because must wait for the imformation.

To be honest, I can't see message working if we cannot send without latency, I assumed it would be like this all along. This way if I was sending a message to the camera, and then immediately I needed to check the changes to that camera, I could. Otherwise I would need to setup some kind of strange timing method in which I sent the message to make the change to the camera, and then I'd have to find a way to know once that message had finished so that I could properly check for the change.

Basically what it comes down to, is that to send a message instantly, you cannot go through a queue, and must route the message as soon as .sendMessage() (or whatever) is called. This does of course imply it must be efficient. I believe the routing of messages can be setup on a hash table of some sort that is created during compile time.
Jan 15, 2008 at 11:38 PM

LordIkon wrote:
The message is basically routed. Each manager/handler defines the messages it will handle, and then when you send the message, in that message you indicate which manager/handler you desire the message to go to.


This would indicate that custom manager/handler would then be unable to intercept these messages. Once a manager has been set it cant be changed.


LordIkon wrote:
You can specify the method in which you want to send a message. You can send it, requiring that is come back instantly, so that you can use its information immediately after you send it. Or, you can send the message to the queue and assume it will get done as soon as it gets the chance. If you send the message to a queue however you cannot immediately use the information that message will return, and your game logic cannot assume that whatever you wanted that message to do has already been done (at least not immediately).


How do you envision this, a server message wouldn't know about any custom game methods, how would you make the keyboard send it's state to a specific custom camera in order to move it forward? Sending a message to the queue and have it execute imediately is dangerous, as update might already have been invoked on the entity getting any state from it is not safe, i.e.moving a camera might not update the frustrum until update is invoked.


LordIkon wrote:
If we are forced to have a frame or more of latency then the example I posted becomes impossible (at least in that format), because must wait for the imformation.


If you need any specific data from a entity or system, you could just invoke it directly, here the problem becomes that if it's possible to update the state out of update then you will not know if the entity is correctly updated.


LordIkon wrote:
To be honest, I can't see message working if we cannot send without latency, I assumed it would be like this all along. This way if I was sending a message to the camera, and then immediately I needed to check the changes to that camera, I could. Otherwise I would need to setup some kind of strange timing method in which I sent the message to make the change to the camera, and then I'd have to find a way to know once that message had finished so that I could properly check for the change.


Well there isn't really any latency as you send a message in your cycle, then the system sends the messages on the next cycle before the entities are updated, this means that messages are send and in the next update all states are resolved. Updating out of sync can be problematic.


LordIkon wrote:
Basically what it comes down to, is that to send a message instantly, you cannot go through a queue, and must route the message as soon as .sendMessage() (or whatever) is called. This does of course imply it must be efficient. I believe the routing of messages can be setup on a hash table of some sort that is created during compile time.


You do not need instant you just need to have it propergated before next update which does happen.
Coordinator
Jan 16, 2008 at 6:35 PM

Sturm wrote:
How do you envision this, a server message wouldn't know about any custom game methods, how would you make the keyboard send it's state to a specific custom camera in order to move it forward? Sending a message to the queue and have it execute imediately is dangerous, as update might already have been invoked on the entity getting any state from it is not safe, i.e.moving a camera might not update the frustrum until update is invoked.


You wouldn't send the keyboard state to the camera. The camera requests keyboard states through a message.

What is comes down to is normal programming techniques become invalid. If I have information A, B, and C. I need A to determine B, which will set the information in C. Normally in programming, you would do something like:

public void doSomething()
{
Get A (through message or function)....

Using info from A, now we can determine info in B....

Using B, we are now able to setup C.
}

You're telling me this will not be possible anywhere in the engine, which make simple things now seem incredibly difficult or time consuming. What I envision now is having to have many different functions that listen for messages and then act on those. If I cannot request the information for A when I want to, then how do I know when I can perform that action?

The sending of a message, in my opinion, needs to act just like a function. When I call a function, it happens immediately, and the function recieves information, and processes it, does some action and/or returns information back to me so that I may take this information and continue on with it.

The reason we use a message system is to replace function calls across managers/handlers. I believe if we're going to replace functions that we should create messages that act like one, or at least very similar.
Jan 16, 2008 at 11:53 PM
Edited Jan 16, 2008 at 11:53 PM

LordIkon wrote:
What is comes down to is normal programming techniques become invalid. If I have information A, B, and C. I need A to determine B, which will set the information in C. Normally in programming, you would do something like:


I might just be ruined after all, but could you describe these normal programming techniques. I mean I've worked on AS systems, custom hardware, drivers and implemted my own OS a few times, but I've never heard about normal programming.

That aside you are describing the system I proposed in Engine structure and design
Coordinator
Jan 17, 2008 at 4:21 PM
If you proposed that system in the first place then I am sorry I didn't notice it then, it certainly wasn't intentional.

When I say "normal" I basically mean traditional game programming techniques. My basis for normal is only from experience. I've only seen code from a couple engines and published titles, but my degree focused specifically on game programming so I saw a fair share of code samples and books that talked specifically about game engines and game development. So by no means is my word or knowledge the law, it is just what I know to be the norm, thus far. I'm open to other ways, I'd just like to keep things as close to the standard as possible.

I think part of what is nice about you, I, and Shaw, is we seem to have completely different views on programming techniques, and different focuses. That means we see all the points of view, and we're not just limited to a small subset of them.
Jan 17, 2008 at 10:49 PM
There is a big difference between writing game code and engine code. It's not unusual that the game code employs wastly different termilogies than engine code does. There are many engines which uses a scripting language (such as Lua or AngleScript) and more often than not employs procedural coding paradims. Even thought the scripting language would use oo concepts the game code is written as procedural code.

This is perfectly ok and a proven model, here the engine does all the work and just invokes the script at the right time. In that sense it's right that the messaging system seems odd, but the messaging system would not be exposed here. There would most likely be Mouse/Keyboard object which would expose the needed information to the scripting language.
Coordinator
Jan 17, 2008 at 11:28 PM
Yes, but when I am writing game code, like in the examples I've posted, I'd like the messaging to work in that fashion. Just my preference.
Jan 18, 2008 at 12:25 PM
Edited Jan 18, 2008 at 12:26 PM
I wouldn't expect the game code to be integrated into the engine. I would perfer that we write that on top of it, i.e. using a scripting engine. In the script you woun't want to use the GameMessage event, most likely it's not even accessible, instead you would most likely query a System object for the state of the keyboard.
Coordinator
Jan 18, 2008 at 4:49 PM
I agree I would query the state of the keyboard, but the main issue is that when I query it, it would have to be somewhere else in the code that handles it.

Here is how I see it happening as the code currently is:
Something handles keyboard input messages, and when we receive that message call some other function to act on it.

Here is how I believe it would happen if we didn't have messages, and just used functions:
Send a function retrieve the state of a specific keyboard key, return true/false, now act on the returned boolean.

Here is how I believe it would happen if our messaging was instant:
Send a message to query the state of a specific keyboard key, return true/false, now act on the returned boolean.

A little structure example might help:
Here is how it is now....
// complete pseudocode, not based exactly off current system
public void HandleKeyboardMessages(MessageType keyboardKey)
{
      if ( keyboardKey == Key.A )
     {
               // Call another function or perform an action here 
     }
 
     if ( keyboardKey == Key.W )
     {
               // Call another function, etc....
      }
}

Here is what I'm used to as a game programmer....

public void DoStuff()
{
          ....doing stuff....
          ....doing more stuff....
 
          send message to ask if the A key is being pressed
          if ( msg.Key.A == KeyState.pressed )
          {
 
          }
}

The HUGE difference here might not be glaringly obvious. What instant messages means I am able to do is query anything I want at any place in my code, and not have to wait to act on it. Without this ability I am forced to handle all of a specific message type in a function, and act on the messages all at once.

With instant messages I can say this:

Do action A,
Do action B through a message send,
Do action C based on Action B's message.

Without instant messages I have to do this:
Have function to check all messages,
Upon recieving a message for action B, perform action A, then using the information from B do action C.

I guess this is similar to what I've already talked about. The reason I'm making a big deal out of this is because it complete changes the way I would be writing my game as a game-writer. To me it changes the entire structure of game programming.

Normally I could have an update function that performed 10 things, in order, and all 10 of those things depended upon information from the thing before it. If any of those 10 things required information from another system (which means a message), and that message information couldn't return instantly, then I'd have to re-write the entire update function.
Jan 18, 2008 at 6:52 PM

LordIkon wrote:
I guess this is similar to what I've already talked about. The reason I'm making a big deal out of this is because it complete changes the way I would be writing my game as a game-writer. To me it changes the entire structure of game programming.

Normally I could have an update function that performed 10 things, in order, and all 10 of those things depended upon information from the thing before it. If any of those 10 things required information from another system (which means a message), and that message information couldn't return instantly, then I'd have to re-write the entire update function.


You are still trying to push game implementation into the engine. You have to think about it something like this:

The full engine is

Game Layer - This is written in scrips and does not interact with many of the Engine systems
Engine Layer - This is responsible for invoking and updating the game layer
Network Layer - Responsible for sending messages/states to all players

Currently it's a lot more complicated writing a game using the engine, but scripting is planned for 0.21 so at that time it should become much easier implementing a game.
Jan 18, 2008 at 8:38 PM
Edited Jan 18, 2008 at 8:39 PM
"Currently it's a lot more complicated writing a game using the engine,..."

Yes, you can say that! Instead of making it easy, right now it is very hard to understand what if going on and what to do. I hope the script system make this more easy.
Coordinator
Jan 18, 2008 at 9:03 PM
I think I got caught up in messaging and missed something.....but, scripting?

The only engines I've used scripting with were Unreal and Torque. Unreal was scripting-only unless you were paying for the full engine code. Torque had code and scripting. And I might add that getting a whole lot from the engine wasn't easy from either through scripting. Now I'm not saying that scripting is bad, but as everyone is going to have the full code to the engine anyway, I don't see them using it for a whole lot (unless I'm missing something).

It is difficult right now to see what is going on, because we haven't really designed the heart of the program, which is the scene manager. Once we get some better managers and a fully designed scene manager I think it will come together a lot better.
Jan 18, 2008 at 9:11 PM
You can say that. But it's like comparing an OS. If you start your developing at he core level everything is complicated. But writing at application level makes it much easier to do.

Today you wouldn't use DX to write a game most likely you would find a game engine which abstracted all that, possible into a scripting language, and not really care about engine implementation.

We are currently at a stage where the engine only implements a few features, and in a sense isn't really an engine. As more and more features get implemented and our application layer matures (either through a defined interface or scripting) into a useable environment we are getting closer to creating a game engine, at which time it should be easier to create a game.
Jan 18, 2008 at 9:47 PM
There are plenty of engines using scripting:
  • GameStudio
  • C4
  • Unity
  • Visual3D.Net
  • CryEngine2
  • Etc

Scripting provides a powerfull extension to engines, allowing customers to create their own extensions without the need to modify the engine. It seems that the genneral attitude is; They have the source, they can do what they want. While true, you won't get too many games release this way. When looking for a game engine you want to find one which provides the features needed, and allows to extend it without touching the base code. The main reason fot this is that as soon as you start customizing the engine, the creating team usually do not support it anymore.

So anything we can do to help game developers and keep them away from modifying the base code is a good step towards more releasing games.
Coordinator
Jan 18, 2008 at 11:38 PM
I agree the develops shouldn't have to use the code base, but I believe they will be directly using the code base in their own code.

I'm not ruling out scripting, it can be very powerful, and I was planning on using it for things like A.I. anyhow, I'm just saying that scripting won't be the only thing.
Jan 19, 2008 at 12:48 AM

LordIkon wrote:
I agree the develops shouldn't have to use the code base, but I believe they will be directly using the code base in their own code.


Devs will of cause extend our code base and we need to think about how that's done. But I don't think we should have it as a design goal that they would use the engine interface directly, why would you if you can use script?

I envision it much like the VS WinForms Editor, you insert an entity or select one, in the properties window you select the event tab and then dbl click on the Collide event, this opens the script editor and you can write the code needed for the collide event.


LordIkon wrote:
I'm not ruling out scripting, it can be very powerful, and I was planning on using it for things like A.I. anyhow, I'm just saying that scripting won't be the only thing.


I'm aware that most likely devs need to tweak the engine to fit their game, but I think our design goal should be that devs shouldn't have to touch the engine directly. This makes supporting and upgrading much easier, as there's no custom code in the base engine.
Jan 19, 2008 at 12:58 AM
This thread is getting off topic, we should move design discussions to Engine structure and design.

You should be able to implement the GamePad using the current system, we might then consider adding an InputMapper or something similar which the devs can query for the state of a button or key. But this is outside the scope of 0.19, which I really would like to see being released.
Jan 20, 2008 at 11:59 PM
Patch 689 Comments

Performance: 800 kb of allocation over about 20 seconds of flying around the terrain. Some of this is just allocating new ObjectPool messages over the first few frames. Most of it, however, is in the camera update routine by the recreation of the Frustum objects. This is a known issue that I've mentioned before, and it's not causing us must in the way of garbage. Bottom line: no problems here so far!

I haven't ran it through NProf, but I don't see the need.

DebugScreen.cs:
  • I'll definitely a close look at your suggestions for the Compositor for 0.20.
  • Is there a limit to the number of key messages per frame? If I hold down more than 6 keys (don't ask me how), it only shows 6 in the debug panel. I know PS/2 keyboards had a hardware issue with this, but I thought USB keyboards did not.

KeyMessage.cs:
  • Missing XML comment on AssignCore() (are we requiring comments on protected methods?)
  • Missing source header
  • Missing XML class summary

KeyData.cs:
  • Missing source header

MouseButton.cs:
  • "using System;" is unneeded. (Sorry, I couldn't resist!)

KeyboardHandler.cs:
  • Missing XML comments on VerifyControlKeys (again, see comment above)

ExitMessage.cs:
  • Missing source header

MessageType.cs:
  • Class XML remarks are inconsistent. Engine messages are now beyond 0-1000 and Int32.MinValue is not -1 for unknown types.

Everything else appears fine. I didn't pay too much attention to the Scene/SceneManager/Entity/Camera classes, since those will all be touch rather thoroughly by the scene redesign.

Jan 21, 2008 at 12:13 AM
Regarding scripting, a project like this is somewhat more unique in what it defines as "scripts." In typical C++ games, you have an engine written in C++ and game logic written in Lua, Python, AngelScript, UnrealScript, or whatever proprietary language the game engine uses. For our porposes, "scripting" will most likely be done in C#.

The way I see it breaking down is we have two layers: the engine layer and the game layer. Right now all of our code is in the engine layer. The game layer is what users will be writing. Even everything in QuickStartSampleGame I would consider to be in the engine layer. Essentially, we will build a layer of abstraction on top of the engine, and provide queriable data to the user code. From user code, you can make calls like "Is key X down" or "Is input key GUN_FIRE down". You will have the choice of just manually registering with the event handlers, or going through the intermediate queriable types.

Point to point messaging is equivalent to function calls, the way I see it. If you want to provide a message of type KeyboardQuery to send to the input system, and wait for a reply, then you're just as well off giving that code access to the input system interface.
Jan 21, 2008 at 5:13 AM
I've updated the code to include the xml comments, my bad for the poor patch.

You we should always provide comments. Developers outside our team are going to look at the source, and someone else might need to take over your code, so provide as many comments as you deem fit, and always provide xml comments.

Nice catch with the using statement. We should always remove all non used statements in order to have as clear code as possible.

Regarding key, I've had this issue all the time as I'm using a ps/2 keyboard, I actually do not know if this is a usb keyboard limit as well. Then again I seldom see the need for pressing more than 6 keys.

When it comes to script, I'm partially agreeing with you. We have a game and a engine layer. As I'm seing it is that when you are in the game layer you shouldn't have to interact directly with the engine layer. Most of the access will be done through some special objects which protects the engine from (intended or unintended) malicious code. As I see it we will have a scripting language. Though I would love to see it being C# :)

I'll try to see if I can mock something up for that ;)