- Memory management - I need to have a firm grasp on the best practices around managing memory in C++ and C#. This was the area where I struggled the most in my interview
- Review all my major works - make sure I can confidently discuss all of my code
- Understand how objects work in c++ and c# - I need to know how objects are stored, passed as parameters and destructed for both c++ and c#
- Shaders - I put on my resume that I am interested in graphics programming, but I have very little experience with shaders.
- 3d math - Need to firmly know all the applications of math operations, not necessarily the formulas.
4/19/10
Bonfire Extinguished
I officially didn't get the Bonfire job. Not a huge surprise, but a part of me was hoping I did get it. I still think I'm really close though. I think my portfolio is good enough to get me in the door now. I need to work on patching up my technical expertise now so I can hold my own in an interview. Here are the areas that I will work on before the next interview:
4/16/10
Interview with Bonfire
I had an interview with Bonfire Studios this afternoon. Bonfire Studios was founded by David Rippy and several other former management members of Ensemble Studios after that studio closed early last year. Getting an interview was much like an oscar nom, its an honor just to have the opprotunity to interview. It gives me confidence that I'm headed in the right direction with my portfolio. That being said, I think there are still areas I need to grow in order to be truly competitive for jobs.
I don't think I completely bombed the interview, but it did shed light on areas that I need improvement on:
I don't think I completely bombed the interview, but it did shed light on areas that I need improvement on:
- C++ memory management - they asked several questions and proposed several scenarios around c++ memory management where the answers were not exactly top of mind. I need to make sure I have a firm understanding of memory allocation, memory management, caching, and best practices in not only c++ but C# as well.
- Know my own s*** - they asked several questions about my wind project and how the algorithm worked. It's been about 3-4 years since I looked at that code. I just happended to read the paper I wrote on it last night, but there is no excuse for me not to know exactly how that system works, be able to comment on the performance of it, and give concrete examples on how to improve it.
- struct vs class - the question was asked "what is the difference between a struct and a class" and I wasn't able to diffinitively answer the question. I need to know this in both C# and C++ and throw in union to that too.
- what type of games do you like - I found myself unable to give a concrete answer to this question. I need to sit down and really think about all the games that I've played, and figure out what I liked and didn't like about each one.
- figure out the performance attributes of stl containers - In the solution to the linked list problem they gave me, I originally used a std::map as part of my solution. That solution proved to be slow. I need to know what about the map caused it to be slow.
- document, document, document - I have a problem sometimes remembering details of the work I've done. I need to make sure that I keep some sort of developer's diary that I update everyday detailing the work that I did. I started doing that with this blog, but got out of the habit, but the days that I did write are the areas that I remember the most.
1/25/10
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:
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.
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
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.
1/11/10
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.
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.
1/4/10
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:
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!
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.
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!
Subscribe to:
Posts (Atom)