So, right now I've been working on the ILGenerics namespace for the framework /What this namespace aims to do is to create a generic implementation of several entities, graphics, resources, states, and actions that are used by various possible entities and actors within a game. These generics can then either be used directly or used as the base classes for other values.
These generics are meant to be the first show of power that the framework has, in that the generics will be some of the most basic types of states, actions, and the like that a system could possibly need. What the namespace will add in general will also be very powerful, giving access to a variety of resources that can aid with making development flow much faster and more fluidly.
I will eventually post the most recent diagrams and documents, which will further explain my reasoning. I need to move the documents to a new host (eventually, probably to a web server I'll rent), which will allow for better configuration management and also allow for all of my work to be hosted from a central repository, rather than on my desktop and backed up on a separate hard drive.
Until later. After these generics are finished, I will finish up the DirectX 9 wrapper classes that allow for the easy creation and extension of DirectX applications, and then will begin on creating my first game with the engine, a proof of concept of how powerful and flexible it can be.
That's it for now.
Oh, also of good note is that I got my personal website up. It can currently be found either at http://www.se.rit.edu/~brb6127 or http://people.rit.edu/brb6127. Feel free to look and investigate my previous work.
Thursday, July 23, 2009
Thursday, July 16, 2009
IL Framework Progress
Well, yesterday I finished working on the basic IL framework for C++, getting it to compile into both DLLs and Libs for both Debug and Release mode. My next challenge with it is to wrap several of DirectX's files and formats into the framework. This includes but is not limited to:
* Textures (DirectX supported textures)
* Models (.X files for now... may expand later)
* Shaders (HLSL/CG files using ID3DXEffect files and the like)
By then wrapping the actual D3D device inside of the application part of the framework, it should be possible to setup and initialize a D3D application that will run and continue working until the system calls it to quit. From there, I will think about abstracting out the ID3DXSprite interface for drawing sprites to a scene. This will then be applied to a first short game, modeled after one of my Computer Graphics I projects, which will be fully 3D, use DirectX and HLSL for rendering, and finally utilize the interactions system of the framework for game play mechanics.
* Textures (DirectX supported textures)
* Models (.X files for now... may expand later)
* Shaders (HLSL/CG files using ID3DXEffect files and the like)
By then wrapping the actual D3D device inside of the application part of the framework, it should be possible to setup and initialize a D3D application that will run and continue working until the system calls it to quit. From there, I will think about abstracting out the ID3DXSprite interface for drawing sprites to a scene. This will then be applied to a first short game, modeled after one of my Computer Graphics I projects, which will be fully 3D, use DirectX and HLSL for rendering, and finally utilize the interactions system of the framework for game play mechanics.
Monday, July 6, 2009
Looking Into Procedural Content
Well, right now I'm working on a project which will create a randomly generated graph, based on some parameters fed into the system. The graph will then be displayed and be editable by users. Next, after the graph is displayed, the system will export the graph into a format for being read.
Here comes the fun part: take the graph and edges, with weights to specify distances and values to specify sizes, and create terrain or a dungeon from it. From there, make the dungeon exportable to either Maya or 3D Studio Max.
Right now, I'm in the planning stages of developing this software. Currently, the system utilizes a rough system of vertices and edges to create the graph. However, the goal is to surpass that and allow for cycle detection and the like, which can be used for vertex reduction and complexity reduction for the graph.
Here comes the fun part: take the graph and edges, with weights to specify distances and values to specify sizes, and create terrain or a dungeon from it. From there, make the dungeon exportable to either Maya or 3D Studio Max.
Right now, I'm in the planning stages of developing this software. Currently, the system utilizes a rough system of vertices and edges to create the graph. However, the goal is to surpass that and allow for cycle detection and the like, which can be used for vertex reduction and complexity reduction for the graph.
Wednesday, June 10, 2009
Development Perspective: Graphics APIs or Graphics Engines?
In this post, I'd like to take a step back from personal projects and happenings and discuss a point of view that was raised in dialogue during a class:
Student: "Which is better: Learning a graphics API or learning how to use a graphics engine?"
Professor: "Well, what are you trying to do?"
Student: "I'm a game programmer! I want to make games with cool graphics!"
Those were words spoken and raised an interesting question which made me think about this from a game development standpoint: which is better to learn?
Well, after digging around, I came up with quite a few different answers, so here's my take on the issue and the pros and cons of the two approaches.
When we talk about graphics APIs, we assume we're talking about something like DirectX or OpenGL, at least in the games world, or whatever platform specific graphics API we're using.
What we gain from knowledge of an API is usually allot of nice information on how the graphics pipeline is handled for that specific type of system. This allows us to not only know the process of what happens when we attempt to place, light/shade, and display the objects in our scene, but it also allows to know how to perform lower level, specific calls to enhance or alter that pipeline, which allows us in many ways, a high level of customization and flexibility with our graphics.
What we often lose here though is the bigger picture. With doing low level shading designs and protocols, tweaking the OpenGL state machine for specific functionality, or making DirectX properly flush our vertices to the graphics card, we often do not gain a clear perspective of the needs for content management, scene control and organization, or gain the high level flexibility of being able to make scenes on the fly without having to specify low level constructs, prefering to develop our own methods or ignore previous methods for obtaining niche performance goals or what we consider cool graphics effects.
When we talk about graphics engines, which are often mislabeled game engines, we are usually talking about the rendering engines behind things such as the Unreal Engine (not the engine itself, but the rendering part of it), Open Scene Graph, the Irrlicht Scene Engine, and similar products.
What these offer is usually a higher level of abstraction away from the tiny lighting functions and placement functions, and give us access to many fundamental function and entities for placing and creating graphical scenes. With this comes content management, allot of extra math done behind the scenes for culling and clipping we don't have to implement, and much higher ease of use.
Here though, we lose allot of the customization and performance upgrades we can have by directly interacting with the API. Like it or not, most of these graphics engines eventually play with DirectX or OpenGL to accomplish their goals. As such, the process in which everything happens behind the scenes is often concealed from us with these engines. Because of this, when we attempt to make personal customizations for fancy or advanced graphics, we often are forced down to the API level, and usually have to conform to the order and organization specified by the engine, unless we want to get errors.
Hence, my opinion on this matter is this. For someone that wants to just make a game, without the need or want to make lots of special graphics customizations or the gut to live with what the engine offers you, then going with an engine is a much easier and faster way to get your game running. However, if you want to learn the ins and outs of how the graphics pipeline works to streamline the graphics performance and be able to eventually create more advanced graphics effects, learning an API (or multiple) is a much better approach. Personally, I choose a little of both, liking to delve really deep into the specifics of an API to pull out good performance or awesome effects, while developing those skills to fit into an engine like construct.
Student: "Which is better: Learning a graphics API or learning how to use a graphics engine?"
Professor: "Well, what are you trying to do?"
Student: "I'm a game programmer! I want to make games with cool graphics!"
Those were words spoken and raised an interesting question which made me think about this from a game development standpoint: which is better to learn?
Well, after digging around, I came up with quite a few different answers, so here's my take on the issue and the pros and cons of the two approaches.
When we talk about graphics APIs, we assume we're talking about something like DirectX or OpenGL, at least in the games world, or whatever platform specific graphics API we're using.
What we gain from knowledge of an API is usually allot of nice information on how the graphics pipeline is handled for that specific type of system. This allows us to not only know the process of what happens when we attempt to place, light/shade, and display the objects in our scene, but it also allows to know how to perform lower level, specific calls to enhance or alter that pipeline, which allows us in many ways, a high level of customization and flexibility with our graphics.
What we often lose here though is the bigger picture. With doing low level shading designs and protocols, tweaking the OpenGL state machine for specific functionality, or making DirectX properly flush our vertices to the graphics card, we often do not gain a clear perspective of the needs for content management, scene control and organization, or gain the high level flexibility of being able to make scenes on the fly without having to specify low level constructs, prefering to develop our own methods or ignore previous methods for obtaining niche performance goals or what we consider cool graphics effects.
When we talk about graphics engines, which are often mislabeled game engines, we are usually talking about the rendering engines behind things such as the Unreal Engine (not the engine itself, but the rendering part of it), Open Scene Graph, the Irrlicht Scene Engine, and similar products.
What these offer is usually a higher level of abstraction away from the tiny lighting functions and placement functions, and give us access to many fundamental function and entities for placing and creating graphical scenes. With this comes content management, allot of extra math done behind the scenes for culling and clipping we don't have to implement, and much higher ease of use.
Here though, we lose allot of the customization and performance upgrades we can have by directly interacting with the API. Like it or not, most of these graphics engines eventually play with DirectX or OpenGL to accomplish their goals. As such, the process in which everything happens behind the scenes is often concealed from us with these engines. Because of this, when we attempt to make personal customizations for fancy or advanced graphics, we often are forced down to the API level, and usually have to conform to the order and organization specified by the engine, unless we want to get errors.
Hence, my opinion on this matter is this. For someone that wants to just make a game, without the need or want to make lots of special graphics customizations or the gut to live with what the engine offers you, then going with an engine is a much easier and faster way to get your game running. However, if you want to learn the ins and outs of how the graphics pipeline works to streamline the graphics performance and be able to eventually create more advanced graphics effects, learning an API (or multiple) is a much better approach. Personally, I choose a little of both, liking to delve really deep into the specifics of an API to pull out good performance or awesome effects, while developing those skills to fit into an engine like construct.
Tuesday, June 9, 2009
Working Architecture
So, finally now that classes have died down and I'm on the last stretch of my BS degree in Software Engineering, I am going to cover future plans and the system I have been devoting some of my spare time to, the Inferno Game Engine.
I will be finishing my BS this fall, in November 2009. Following, I have decided to enter into the MS in Game Design and Development, with a focus on Game Engine Architecture and Design and Creative Narrative / World Creation. Instead of going straight into industry, I decided that I really needed more projects under my belt, which RIT's GDD master's program offers. However, I'm still skeptical to a degree about the prowess of such a program, as often academic programs for games do not produce the best game designers, programmers, architects, and the like. For that, I will rely on my SE background.
Now, to get to the meat of this post, I have been working for the past 3 years on a game engine primer, as I like to call it. What the primer does is specify the core classes and interfaces for making a game system which revolves around having in game entities communicate with one another, how they store and track their arbitrary state information, and how they act on one another. While I could have slapped something like this together easily without much forethought, I've decided that I really need to design it out and weigh all design decisions properly before just allowing the system to be programmed. For that, I've gotten quite a bit.
Below is the basic flow of the primer (If the diagrams don't appear right, try clicking on them to get a better view of the diagrams):
The above image gives an overview of the idea of the primer, and how it can be used to create bindings which are then used for making game or simulations, ideally.
The above image here represents the basic class structure of the primer. The movement from left to right moves upwards in the chain of complexity of the different class elements, as it is in short, a large class hierarchy of increasing complexity, to allow for the most dynamic and flexible interactions and storage of entities possible.
The above image here was playing around with how the concept of updating would work for the system. It appears like a standard update loop. The design here is not final.
My reasons for posting these diagrams is because, eventually, I am planning on making the primer and the related bindings open source. Currently planned are Irrlicht Engine bindings and XNA bindings, though more can be added later. The reason for this, as specified, is to create the means by which entities can interact and control themselves. I feel, personally, that there are not enough powerful open source tools for the game community and that powerful, great tools should not be limited to the powerful or those with millions of dollars of funding. While this may not control the quality of games directly by limiting only to those groups, what it does do is provide better tools that will support burgeoning game developers.
And with that, I will leave it for now. I have more work to do, but these should help others to get a better idea of what the engine does, and what I am engaging myself with. Until the next time.
I will be finishing my BS this fall, in November 2009. Following, I have decided to enter into the MS in Game Design and Development, with a focus on Game Engine Architecture and Design and Creative Narrative / World Creation. Instead of going straight into industry, I decided that I really needed more projects under my belt, which RIT's GDD master's program offers. However, I'm still skeptical to a degree about the prowess of such a program, as often academic programs for games do not produce the best game designers, programmers, architects, and the like. For that, I will rely on my SE background.
Now, to get to the meat of this post, I have been working for the past 3 years on a game engine primer, as I like to call it. What the primer does is specify the core classes and interfaces for making a game system which revolves around having in game entities communicate with one another, how they store and track their arbitrary state information, and how they act on one another. While I could have slapped something like this together easily without much forethought, I've decided that I really need to design it out and weigh all design decisions properly before just allowing the system to be programmed. For that, I've gotten quite a bit.
Below is the basic flow of the primer (If the diagrams don't appear right, try clicking on them to get a better view of the diagrams):
The above image gives an overview of the idea of the primer, and how it can be used to create bindings which are then used for making game or simulations, ideally.
The above image here represents the basic class structure of the primer. The movement from left to right moves upwards in the chain of complexity of the different class elements, as it is in short, a large class hierarchy of increasing complexity, to allow for the most dynamic and flexible interactions and storage of entities possible.
The above image here was playing around with how the concept of updating would work for the system. It appears like a standard update loop. The design here is not final.
My reasons for posting these diagrams is because, eventually, I am planning on making the primer and the related bindings open source. Currently planned are Irrlicht Engine bindings and XNA bindings, though more can be added later. The reason for this, as specified, is to create the means by which entities can interact and control themselves. I feel, personally, that there are not enough powerful open source tools for the game community and that powerful, great tools should not be limited to the powerful or those with millions of dollars of funding. While this may not control the quality of games directly by limiting only to those groups, what it does do is provide better tools that will support burgeoning game developers.
And with that, I will leave it for now. I have more work to do, but these should help others to get a better idea of what the engine does, and what I am engaging myself with. Until the next time.
Sunday, March 15, 2009
Requirements, Maintanence, and Games
Looking back on one of the first game projects I worked on, I realize now, more than ever, how important good requirements are, how important good communication and best practices are in designing and developing a software system. My words are not to reflect badly on my employer or the state of their work, as all of it was student based and originally done by one person. It is to instead talk about what was wrong, why it was wrong, and the outcome because of it.
When I started work with the company, it was to focus on the implementation of a centralized game for their project. This game was already planned and was supposed to have good documentation. The first ten weeks of work was to be developing the game, while the last ten weeks was to be polish and maintenance, with extended testing and development as could be offered. However, after coming onto the project, it became quickly evident that the project was not as well planned as we had hoped or thought it would be.
The project had been written mainly by a single programmer, who also was responsible for most of the artwork. For the application, there was very little use of the XNA framework, as when the application was originally made, XNA did not have nice features such as model loading, texture loading, etc. Because of this, it had a very interesting architecture, based around working with the loading of COLLADA files and their only implemented game, a space shooter where you shoot meteors and protect friendly ships. While there did exist an architecture to extend the game, to allow for the centralized colony simulation and other mini games to come on, everything was so tightly coupled to everything else that working off of that base would have been, for lack of a better phrase, nigh impossible.
So, what should have been simple development and integration became the designing of and implementing of a game architecture that would allow for mini-games, a centralized game, and ways of communicating information between them. Along with this, it had to support the original mini-game and also somehow incorporate the particle engine that had been written for the mini-game. This process took approximately 5 weeks to build, and over the course of development for the last 5, the whole time to check maintenance-wise. And with that, came the game development.
Now, there were many ideas for the mini-game the side team was developing, and many ideas for the main game. However, there were no true requirements as to what the games should be. Some said "like SimCity, but in space!". Others were more like Railroad Tycoon in the way the transport systems should work, but they failed to mention what should be transported and how this related to the game system and mechanics. This led to what was, more or less, 5 weeks of prototyping with trying to find the mechanics and requirements that would match the game that our producer wanted, while allowing for what could be a fun and reasonable game. Looking back on this, we could have probably used the full 10 weeks just to get nice requirements and create a strong architecture, but often in industry there isn't that sort of time, nor that kind of foresight.
A result of this process, or lack thereof, has led to many problem during maintenance. Many issues that were not covered have come up, leading to some people implementing improper quick fixes. Another serious issue is, as things have built up, the lack of communication has created severe issues with how issues are handled, which has resulted in some less than sufficient or necessary changes to the project, which have further delayed the beta release.
All in all, requirements, nice, solid, good requirements and good communication would have solved many of these issues. With games, as with any software, the gauge of success and problems often can be traced back to the requirements, or lack thereof.
When I started work with the company, it was to focus on the implementation of a centralized game for their project. This game was already planned and was supposed to have good documentation. The first ten weeks of work was to be developing the game, while the last ten weeks was to be polish and maintenance, with extended testing and development as could be offered. However, after coming onto the project, it became quickly evident that the project was not as well planned as we had hoped or thought it would be.
The project had been written mainly by a single programmer, who also was responsible for most of the artwork. For the application, there was very little use of the XNA framework, as when the application was originally made, XNA did not have nice features such as model loading, texture loading, etc. Because of this, it had a very interesting architecture, based around working with the loading of COLLADA files and their only implemented game, a space shooter where you shoot meteors and protect friendly ships. While there did exist an architecture to extend the game, to allow for the centralized colony simulation and other mini games to come on, everything was so tightly coupled to everything else that working off of that base would have been, for lack of a better phrase, nigh impossible.
So, what should have been simple development and integration became the designing of and implementing of a game architecture that would allow for mini-games, a centralized game, and ways of communicating information between them. Along with this, it had to support the original mini-game and also somehow incorporate the particle engine that had been written for the mini-game. This process took approximately 5 weeks to build, and over the course of development for the last 5, the whole time to check maintenance-wise. And with that, came the game development.
Now, there were many ideas for the mini-game the side team was developing, and many ideas for the main game. However, there were no true requirements as to what the games should be. Some said "like SimCity, but in space!". Others were more like Railroad Tycoon in the way the transport systems should work, but they failed to mention what should be transported and how this related to the game system and mechanics. This led to what was, more or less, 5 weeks of prototyping with trying to find the mechanics and requirements that would match the game that our producer wanted, while allowing for what could be a fun and reasonable game. Looking back on this, we could have probably used the full 10 weeks just to get nice requirements and create a strong architecture, but often in industry there isn't that sort of time, nor that kind of foresight.
A result of this process, or lack thereof, has led to many problem during maintenance. Many issues that were not covered have come up, leading to some people implementing improper quick fixes. Another serious issue is, as things have built up, the lack of communication has created severe issues with how issues are handled, which has resulted in some less than sufficient or necessary changes to the project, which have further delayed the beta release.
All in all, requirements, nice, solid, good requirements and good communication would have solved many of these issues. With games, as with any software, the gauge of success and problems often can be traced back to the requirements, or lack thereof.
Thursday, March 12, 2009
School and Work
On 12/31, I ended my 6 month co-op with the Autism Collaborative. However, I promised to stay on working on a few minor details that needed polishing and provide support where I could for the project.
The project was a game project aimed at Autistic children, between the ages of 10 - 14 (if my memory serves me), with symptoms similar to but possibly greater than those with Asperger's Syndrome.
The game followed a structure in which a large scale game, called the Colony Simulation, served as the center for a set of other "mini games" or "missions" to branch off of. The Colony Simulation would allow players to build a colony in deep space, allowing them to mine for ore, build residential (housing, entertainment) and commercial (stores, factories, mining plants) structures, and link them via a series of "tubes", one for each type of structural connection. This was designed this way based on our producer's experience with Autistic children and their fascinations with machines and mechanical structures. Hence, the simulation was to act like one large machine, when connected.
Each of the mini games or missions are accessible within the Colony Simulation. They can either be selected or they are generated for the user to play. The missions encapsulate many typical and interesting Autism tests, which are used within both a lab setting and data collection setting to collect information about the player.
During this period, I participated in the design, development, and currently the maintenance of the Colony Simulation. My roles primarily included task tracking, completing various tasks, and requirements elicitation (getting ideas and feedback from our producer and my co-workers). I became responsible for many of the user interactions, especially those through the GUI, which I ended up designing the framework and specifications for, since C# does not have a natural GUI implementation for XNA.
Overall, I found the experience very rewarding. Not only does it look great on my resume, but it has helped me figure out many "dos and don'ts" when it comes to games. Also, it's nice to know that what you worked on will help people.
Aside, the maintenance side has come at a hefty price, mainly personal patience and frustration. Since December, I have been enrolled back in school, finishing my Software Engineering degree. It has been difficult to perform maintenance functions, as I have been overloading for the past two quarters (20 credit hours), in order not to only finish my degree, but to also take some of the classes I want to before I graduate.
Overall, the passed several months have been hectic. We're finally at a mid alpha-beta release for the full game, which makes me happy. I am finishing testing on part of the game I have been touching up (score screens and in game artwork). I will post something when we have a release, as well as a means on how to download it.
The project was a game project aimed at Autistic children, between the ages of 10 - 14 (if my memory serves me), with symptoms similar to but possibly greater than those with Asperger's Syndrome.
The game followed a structure in which a large scale game, called the Colony Simulation, served as the center for a set of other "mini games" or "missions" to branch off of. The Colony Simulation would allow players to build a colony in deep space, allowing them to mine for ore, build residential (housing, entertainment) and commercial (stores, factories, mining plants) structures, and link them via a series of "tubes", one for each type of structural connection. This was designed this way based on our producer's experience with Autistic children and their fascinations with machines and mechanical structures. Hence, the simulation was to act like one large machine, when connected.
Each of the mini games or missions are accessible within the Colony Simulation. They can either be selected or they are generated for the user to play. The missions encapsulate many typical and interesting Autism tests, which are used within both a lab setting and data collection setting to collect information about the player.
During this period, I participated in the design, development, and currently the maintenance of the Colony Simulation. My roles primarily included task tracking, completing various tasks, and requirements elicitation (getting ideas and feedback from our producer and my co-workers). I became responsible for many of the user interactions, especially those through the GUI, which I ended up designing the framework and specifications for, since C# does not have a natural GUI implementation for XNA.
Overall, I found the experience very rewarding. Not only does it look great on my resume, but it has helped me figure out many "dos and don'ts" when it comes to games. Also, it's nice to know that what you worked on will help people.
Aside, the maintenance side has come at a hefty price, mainly personal patience and frustration. Since December, I have been enrolled back in school, finishing my Software Engineering degree. It has been difficult to perform maintenance functions, as I have been overloading for the past two quarters (20 credit hours), in order not to only finish my degree, but to also take some of the classes I want to before I graduate.
Overall, the passed several months have been hectic. We're finally at a mid alpha-beta release for the full game, which makes me happy. I am finishing testing on part of the game I have been touching up (score screens and in game artwork). I will post something when we have a release, as well as a means on how to download it.
Subscribe to:
Posts (Atom)