Disclaimer: I'm still pretty ignorant when it comes to a lot of this stuff so don't expect grade-A, dead on explanations.
Okay so what is a Game Engine? It's pretty much all there in the title: It's the engine for the game, it's the power house which can help get a game moving from the get go. In a way, it's pretty similar to a Framework (which are used as a jumping off point for engines) however it comes with a lot more functionality that is designed to streamline the development cycle. One of the major things for engines is that they usually come equipped with the basic necessities for games such as audio, collision and so on. The three basic types of game engines are all-in-one engines, framework-based engines (such as Source) and graphics engines. From what I've understood the all-in-one engines are the ones sort of like Unity where you can make pretty much everything right off the bat with it without needing anything extra while the framework-based ones usually end up spawning some tools that can be utilized with them (i.e. The Source Engine comes equipped with the Hammer Editor which is a tool specifically for building levels that will work with in the engine, as evidence by the ever-increasing list of custom TF2 maps). Then graphic engines just specialize in the rendering process of games and can be used for pre-existing rendering techniques as well as managing scenes and what not. That's more or less a jumbled and quick breakdown of Engines
So like I had mentioned earlier I'm going to talk a bit about two game engines: One I know a fair bit about and the other which I don't know nearly as much about. Let's start with the one that I do know: Valve's Source Engine. So when you purchase a Source game (such as Team Fortress 2, Half-Life, etc.) you get access to a few of the Source engine tools. These include things such as the Hammer Editor, a model viewer, as well as some tools for making mods and so on. The Source Engine is constantly being updated and with it every game that is supported by it, as many owners of Valve games on Steam are aware of when they get little updates for all their games that generally don't do anything to the game itself. This engine is in constant development and because it's an in-house engine for Valve that they can constantly edit it with their own new tricks such as when they introduced a new method of rendering water in Left 4 Dead 2! One key difference between the development of the Source Engine and the next engine I'm going to go into to is that the Source Engine was initially built with a specific game in mind: Half-Life. This gave the team a clear goal when designing much of the features as they knew that they would have to prepare it to be specialized for first-person shooters; a fact which has held true decades later but has been expanded on with time.
So the next engine I'm going to talk about is one that I don't have a whole lot of info on and serves more as a warning for why you should have a single game in mind from the start: Square Enix's Crystal Tools Engine. So this engine has produced some pretty visually impressive games (the entire Final Fantasy XIII collection) and seems to work pretty well...Though, reading up on some stuff revealed that it had a somewhat shaky start off. The engine was initially built with Final Fantasy XIII in mind as the title for it to support but it quickly started taking on multiple projects within the company, each one demanding different specifications and causing the development team to loose track of what they needed to do. This would eventually result in them making it so that some games couldn't even include their assets! So I don't have much to say on this matter other than the fact that this does solidify the importance of having a game in mind from the start.
So that's my technical rambling that's probably missing the mark in a few places...If you want to verbally tear apart everything I've said and you happen to be Dr. Hogue or one of the more well-versed students at UOIT then feel free to tweet me and we can arrange a time to chat over coffee or something!
Now then, on to my last part: My own plans with this information!
...It's not that much of a secret, if you haven't figured it out now then that's genuinely surprising. Obviously I plan to try and begin my own game engine this coming summer. I don't plan to use it for GDW but instead for my own purposes outside of school. I've begun working on a game idea for this engine to be based around but it's still very early in the pre-production stage and with exams and Level-Up looming on the horizon I don't have much time to properly mull things over, so development is pretty much relegated to when I have spare brainpower. The way that things are looking to go, I'll have to put heavier emphasis on making smooth close-combat with irregular shapes which will require creating a more elaborate collision system that works more along the lines of your standard shooter (where each limb has its own box and such) as well as accounting for different shapes. Ideally I'd want to make something similar to Unity where I can toggle between different types of collision but simultaneously be able to add a lot of depth to it. Another heavy emphasis will be on real-time cutscene rendering so I'd like to have something set up that would allow me to easily create a camera track with speed control. I'd also want to put a lot of work into designing a good base for AI as I'll need support for friendly combat AI.
I apologize for the large chunk of text above as this was more me trying to plan it out for myself as well as I find I do develop my ideas better my trying to explain them to others. I'd rather not edit the above area or delete it as I think it does explain a bit more about me as a person...But to summarize it:
Things I will need to emphasize
-A larger variety of collision with varying depths of complexity
-A method of better controlling cutscenes
-A strong AI-base
I also plan on making my engine a framework-style engine so that I can produce some tools to better work with it. Ideally I'd want to create the following:
-A model viewer/render tester: So that I can experiment with different shaders while making sure they run in-game and produce the intended results
-A custom level editor: Ideally one that can take in OBJs and allow me to set up different types of triggers and such
-A cutscene creator: Something similar to the level editor except that I could create a track for the camera to follow and control its speed as it progresses. I also would like to make it so that I could export custom animations for the scene as well as load in level layouts so that I could experiment with moving characters around and seeing how the scene plays out before exporting it as a file type that's easy for the engine to read in at the necessary time.
I recognize that a few of these are probably very unrealistic given my current skill level and I'll probably have a lot of optimization errors in my first pass. I also know that it won't even be close to being a quarter finished by the end of the summer but that doesn't really matter in the end. At the end of the day, even if it doesn't work out I'll still hopefully have learned something or driven myself so crazy that it won't matter anymore!
On that note I'm going to wrap up this post. Now I just need to think of another topic to write about as I already have my final post planned out to some degree. Cheers for now!
Side-note: I am well aware that we take Game Engines in 3rd year, I'll be picking up the copy of my textbook from home after Level-Up. I also know I could have just waited before starting something like this, but as Dan Buckstein can attest: I very rarely wait until it gets taught in class.
So like I had mentioned earlier I'm going to talk a bit about two game engines: One I know a fair bit about and the other which I don't know nearly as much about. Let's start with the one that I do know: Valve's Source Engine. So when you purchase a Source game (such as Team Fortress 2, Half-Life, etc.) you get access to a few of the Source engine tools. These include things such as the Hammer Editor, a model viewer, as well as some tools for making mods and so on. The Source Engine is constantly being updated and with it every game that is supported by it, as many owners of Valve games on Steam are aware of when they get little updates for all their games that generally don't do anything to the game itself. This engine is in constant development and because it's an in-house engine for Valve that they can constantly edit it with their own new tricks such as when they introduced a new method of rendering water in Left 4 Dead 2! One key difference between the development of the Source Engine and the next engine I'm going to go into to is that the Source Engine was initially built with a specific game in mind: Half-Life. This gave the team a clear goal when designing much of the features as they knew that they would have to prepare it to be specialized for first-person shooters; a fact which has held true decades later but has been expanded on with time.
So the next engine I'm going to talk about is one that I don't have a whole lot of info on and serves more as a warning for why you should have a single game in mind from the start: Square Enix's Crystal Tools Engine. So this engine has produced some pretty visually impressive games (the entire Final Fantasy XIII collection) and seems to work pretty well...Though, reading up on some stuff revealed that it had a somewhat shaky start off. The engine was initially built with Final Fantasy XIII in mind as the title for it to support but it quickly started taking on multiple projects within the company, each one demanding different specifications and causing the development team to loose track of what they needed to do. This would eventually result in them making it so that some games couldn't even include their assets! So I don't have much to say on this matter other than the fact that this does solidify the importance of having a game in mind from the start.
So that's my technical rambling that's probably missing the mark in a few places...If you want to verbally tear apart everything I've said and you happen to be Dr. Hogue or one of the more well-versed students at UOIT then feel free to tweet me and we can arrange a time to chat over coffee or something!
Now then, on to my last part: My own plans with this information!
...It's not that much of a secret, if you haven't figured it out now then that's genuinely surprising. Obviously I plan to try and begin my own game engine this coming summer. I don't plan to use it for GDW but instead for my own purposes outside of school. I've begun working on a game idea for this engine to be based around but it's still very early in the pre-production stage and with exams and Level-Up looming on the horizon I don't have much time to properly mull things over, so development is pretty much relegated to when I have spare brainpower. The way that things are looking to go, I'll have to put heavier emphasis on making smooth close-combat with irregular shapes which will require creating a more elaborate collision system that works more along the lines of your standard shooter (where each limb has its own box and such) as well as accounting for different shapes. Ideally I'd want to make something similar to Unity where I can toggle between different types of collision but simultaneously be able to add a lot of depth to it. Another heavy emphasis will be on real-time cutscene rendering so I'd like to have something set up that would allow me to easily create a camera track with speed control. I'd also want to put a lot of work into designing a good base for AI as I'll need support for friendly combat AI.
I apologize for the large chunk of text above as this was more me trying to plan it out for myself as well as I find I do develop my ideas better my trying to explain them to others. I'd rather not edit the above area or delete it as I think it does explain a bit more about me as a person...But to summarize it:
Things I will need to emphasize
-A larger variety of collision with varying depths of complexity
-A method of better controlling cutscenes
-A strong AI-base
I also plan on making my engine a framework-style engine so that I can produce some tools to better work with it. Ideally I'd want to create the following:
-A model viewer/render tester: So that I can experiment with different shaders while making sure they run in-game and produce the intended results
-A custom level editor: Ideally one that can take in OBJs and allow me to set up different types of triggers and such
-A cutscene creator: Something similar to the level editor except that I could create a track for the camera to follow and control its speed as it progresses. I also would like to make it so that I could export custom animations for the scene as well as load in level layouts so that I could experiment with moving characters around and seeing how the scene plays out before exporting it as a file type that's easy for the engine to read in at the necessary time.
I recognize that a few of these are probably very unrealistic given my current skill level and I'll probably have a lot of optimization errors in my first pass. I also know that it won't even be close to being a quarter finished by the end of the summer but that doesn't really matter in the end. At the end of the day, even if it doesn't work out I'll still hopefully have learned something or driven myself so crazy that it won't matter anymore!
On that note I'm going to wrap up this post. Now I just need to think of another topic to write about as I already have my final post planned out to some degree. Cheers for now!
Side-note: I am well aware that we take Game Engines in 3rd year, I'll be picking up the copy of my textbook from home after Level-Up. I also know I could have just waited before starting something like this, but as Dan Buckstein can attest: I very rarely wait until it gets taught in class.
No comments:
Post a Comment