Need a little input on this process

It's been a bit since my last post, but I've been hard at work the whole time.  Since my last post I've added two new systems to my engine, a process manager and an input processor.

Process Manager
Once again, I gained inspiration for this system from Game Coding Complete.  A process is defined as anything that has the ability to change the state of an object.  The idea is that all game logic will be defined in processes.  In my code I have a base class named Process from which all processes must derive from.  The class has two main virtual functions, VInitialize and VUpdate.  VInitialize is called when the process first starts processing while VUpdate is called each time through the main loop.  

An example of a process would be a physics process.  The job of the physics process is to change the state of the world based on certain game events.  So for example,  the physics process receives an event telling it to move a player left.  The physics process, using logic defined in its physics engine, determines the new position of the player and sends an event to the player object notifiying it of its new position.  

As you can see, this allows for a clear separation between game logic and game rendering.  The rendered player object doesn't know or really care how it moves, it just needs to know where it is so it can render it there.  This also provides a clear separation between game logic and user input.  From the example above, I just sent a move player left event, not a key A was pressed on the keyboard event.  The physics process doesn't care why or who is moving the player left, it just knows it needs to move the player left.  It also doesn't care who the player is.  It doesn't know whether it is a human player or an AI player.



The job of the process manager is pretty straight forward.  Any process that needs to run needs to be attached to the process manager.  Each time through the main loop, the process manager's Process method is called in which it goes through all the processes that are attached and calls their VUpdate method.  


Input Processor
The input processor is the system that handles all the raw input from the user.  My engine supports three types of input devices: keyboard, mouse, and gamepad.  I use DirectInput to set up and retrieve the state of all the devices. 

Direct input can be a bit cumbersome at times.  For example, it takes 5 different DirectInput calls to setup and acquire a keyboard or mouse respectively.  First you must create the device which gives you a pointer to access the devices settings and state.  Next you set the data format which is the format of the data returned when you get the device's state.  Then you have to set the cooperative level, telling Windows how to behave when the game window does not have focus.  Now, if you want to set up buffered input rather than just getting the current state of the device, which you will want because it is possible to for example hit multiple keys between two frames, you have to describe the buffer to direct input.  Once all of that is set up, you have to acquire the device, which gives you control over the device, until windows takes back control of the device which can happen if your game loses the focus such as the player hits alt-tab, in which case you have to reaquire the device in order to use it again.  

What's really frustrating about all that is the DirectInput api hasn't really changed in several years.  The last release was DirectInput 8.0 which came out with DirectX 8 which is now in 11.0!  You would think it wouldn't take too much work to clean up and simplify.  And I haven't even gotten into game pad support!


Microsoft introduced a new input api called XInput which handles input from Xbox 360 controller, and only Xbox 360 controllers.  The XInput api is rather simple, but if you want to use any gamepad and still use XInput, you have to determine which connected gamepads support XInput, which currently there is no api call to determine that.  The only solution Microsoft offers is this one.  Their method goes through all the devices connected to the computer and tries to figure out if it is a Xbox controller.  The problem here is that it is looking for a specific device id which only the official xbox controllers have.  So if you're cheap like me and have a third party controller because you thought paying full price for a wired controller was silly, then this method won't work for you.  


So enough on my DirectInput rant.  What does the input processor do besides process input?!?  Seeing as how ugly directInput can be, the input processor allows me to seperate all raw input from the rest of the game engine.  Instead of my game logic interpreting raw input, I create events for each input I receive.  The following is the list of events the input processor can trigger:

• KeyboardEvent - The state of a keyboard button has changed, either being pressed or released
• MouseButtonEvent - The state of a mouse button has changed, either bing pressed or released
• MouseMovedEvent - The mouse has moved
• GamepadTriggerEvent - The state of the trigger on a gamepad has changed
• GamepadButtonEvent - The state of a gamepad button has changed
• GamepadDirectionpadEvent - The state of a gamepad direction pad has changed
• GamepadThumbstickEvent - The state of a gamepad thumbstick has changed

I haven't implemented it yet, but my plan is now to create an input interpreter which will listen for these event and create the proper game event mapped to the input.  I envision having a different  input interpreter for each state of my game (menu, playing, etc).  I can also allow for user configuration of the controls, since my input is completely separated from my game logic.  


It really feels like my engine is starting to come together.  My next step will be to implement a game state system.  More info on that to come.

 

The big event

I added another major component to my game engine this week, the event manager.  The event manager will, um..., manage events!  It will be responsible for the communication between all processes in the game.  The manager tracks two sets of data, event types and event listeners.

Each event that is created will have its own unique name or "event type".  In order for an event to be processed by the manager, its event type must first be registered by the manager.  When an event type is registered, the event manager initializes a container that will store all the listeners for that event.  If a system attempts to trigger an event that is not registered with the manager, the manager will reject the event.

Event listeners are the objects that handle the events processed by the event manager.  When a system wants to listen for events, it will register a listener with the event manger for the type of event it wants to listen to.  Each time an event is processed, all the listeners that are listening for that particular event type will have thier HandleEvent method called.

The event manager allows for two ways of processing events, triggering an event immediately, and queueing the event to be run the next time the event queue is processed.

The architecture of this event manager is once again based heavily on the engine described in Game Coding Complete.  I didn't do any copy paste on this one, but I did consult the book and the source code quite a bit to make sure that  what I was doing was consistent with the book.  Coding the event manager myself definitely gave me a better understanding how it worked than when I just read through the book the first time.

Another thing I did in the development was write unit tests for the event manager.  I didn't use any unit testing frameworks, I just created methods that wrote to the console the name of the test and whether or not it passed or failed.  In the case of a failure, I would simply debug the test that failed.  I've become a big fan of unit testing as a means of testing code, especially in this instance, where as of right now, I don't have a game in place yet to test the event system. 

I'm going to stick with the manager theme for my next project,  I'm going to start work on the process manager. Processes that need to be included in the current state of the game will be registered with the process manager, and the process manager will loop through it's registered processes each frame update.

Merry Christmas, Happy New Year, now back to work!

It's been around three weeks since I've done some serious game development work. I somehow survived the holidays and now I can finally get back to work. The contract with my current employer ends on March 31st so I see this as having 2 months of heavy game development work and 1 month to heavily market my self to game development companies to put my self in a position to get job offers around the time my contract runs out.

I have 3 objectives in the next 2 months:

• Create 2 fully functional games
• Networking, Networking, Networking (the majority of this is going to have to be online due to a lack of in person events in my area)
• Get a firm grasp of how to develop for the iPhone.

The first step is pretty straight forward.  Pump out a game a month.  I'm setting hard deadlines for myself on these, because I need deadlines.  My plan is to finish the Tetris clone by the end of January and create another game in February hopefully using code from Tetris clone as a good base.

Step 2 is where it gets interesting.  If you're reading this hopefully some of my networking ventures are working.  Dallas is rich in game development companies, including some heavyweights like Id, Gearbox, and Terminal Reality, but for some reason, the local Dallas IGDA chapter is practically dormant.  So my networking assault is going to be mostly online.  I'm of course writing this blog as a means of networking and self promotion, but I've started by trying to find anyone I've ever worked with for game development on social networking sites so I can connect with those already in the industry.  Hopefully by the start of March, I'll have a lot of momentum on the networking front.

The last one is a bit diffrent.  There are quite a few iphone dev's here in Dallas, and while I do own an iPhone, I've never developed an app, so inorder to broaden my chances, I wan't to learn objective-c and maybe make my third game an iphone game.  There is some overhead costs I'll have to incur here to do this (like buy a mac). But you have to spend money to make money right. 

So thats the 3 month "Game Dev Blitz" I've set out for myself.  Call it a New Year's resolution to break into the game dev industry.  Should hopfully be pumping out these blogs nightly as I start some serious development on my games.  Very exciting!