Ok, so you now know why I'm making this. It would only be fair to tell you how I plan to do it, or at least how I think I'm going to.
Derange is being fully written in Visual C++ 2008. This was not a very easy decision to make, since I had never written anything in that language before. I'm very comfortable developing in C# and .NET, since I've been using those at work for a long time now. I love how tidy, flexible and powerful they are. However, there are some important drawbacks to using them for game development, as I found out:
Derange is being fully written in Visual C++ 2008. This was not a very easy decision to make, since I had never written anything in that language before. I'm very comfortable developing in C# and .NET, since I've been using those at work for a long time now. I love how tidy, flexible and powerful they are. However, there are some important drawbacks to using them for game development, as I found out:
- Ogre3D is written using VC++. Even though there are ports to use it with other languages, they will always be behind schedule when releasing updates, and there might be bugs in the porting process.
- .NET code is executed in a virtual machine, which is of course much more resource intensive and slower than plain old native code.
- I think most of the game development resources out there are targeted to the C++ developer, and being one in a learning process, this was quite important.
- I understand VC++ is the industry standard when it comes to game development.
Usually I like to plan development prior to get my hands on it, and have the big picture in mind to identify any possible design flaws before they become a problem that's hard to fix. Given the size of this project (Don't forget I'm the only one working on it) and that I'm still learning, that didn't sound realistic at all, as I can only anticipate what's coming up to a certain point. So I decided I would design and redesign as needed, on the fly, as I see fit.
This means that I might end up completely rewriting entire sections of code. Many times. And actually, I already have by now. I believe each code component should be as modular, reusable, and decoupled from other components as I can make it to be, so that when I need to take a different approach with something, there's not so much I need to change.
Before getting into game specific tasks like handling entities, animation, conversations, etc., I decided to focus on the "skeleton" of the engine. Things like basic engine initialization, handling input, resources and events in general, running Lua scripts and the like. I think this really needs to be dealt with first, because everything else I code will depend on how the skeleton is laid out. If it's not flexible enough, there will come a time when I have to redesign it, and probably rewrite most of the code that depends on it. Which would of course make me shit bricks and is not acceptable in any way.
I redesigned this skeleton many many times back when I started, and it still needs a little tidying, but by now I'm fairly comfortable with its general design. I'll get into the specifics and some diagrams in the following posts.
I don't plan on reinventing any wheels, so I also chose some free, open source, third party tools for some specific tasks. (I might add more or switch to different ones in the way)
This means that I might end up completely rewriting entire sections of code. Many times. And actually, I already have by now. I believe each code component should be as modular, reusable, and decoupled from other components as I can make it to be, so that when I need to take a different approach with something, there's not so much I need to change.
Before getting into game specific tasks like handling entities, animation, conversations, etc., I decided to focus on the "skeleton" of the engine. Things like basic engine initialization, handling input, resources and events in general, running Lua scripts and the like. I think this really needs to be dealt with first, because everything else I code will depend on how the skeleton is laid out. If it's not flexible enough, there will come a time when I have to redesign it, and probably rewrite most of the code that depends on it. Which would of course make me shit bricks and is not acceptable in any way.
I redesigned this skeleton many many times back when I started, and it still needs a little tidying, but by now I'm fairly comfortable with its general design. I'll get into the specifics and some diagrams in the following posts.
I don't plan on reinventing any wheels, so I also chose some free, open source, third party tools for some specific tasks. (I might add more or switch to different ones in the way)
- Lua: A scripting language widely used for game development, it's what makes a specific game "drive" the engine.
- LuaBind: Binds VC++ classes to Lua classes, making them available from scripts.
- Xerces C: Allows to read, write, and validate XML data.
- OgreMax: Imports scenes created in 3DStudio Max into Ogre3D.
- OIS: Handles input devices like keyboards, mice, gamepads, etc.
After the skeleton was mature enough, I started focusing on the actual game objects and their functionality. Things that can move, animate, walk a given route, talk, interact, and much more. Some examples of game objects would be cameras, lights, actors, particle systems, and the player himself.
So the plan up to this point is to keep polishing this skeleton as it becomes necessary, developing more game objects and testing them in a sandbox scene where I can see all their functions in action. I'll be deciding the order in which to implement this functionality on the fly, most probably based on whatever I feel like doing next at each point. :)
So that's it for now. I'll give more details on how the current design looks like in the following posts.
So the plan up to this point is to keep polishing this skeleton as it becomes necessary, developing more game objects and testing them in a sandbox scene where I can see all their functions in action. I'll be deciding the order in which to implement this functionality on the fly, most probably based on whatever I feel like doing next at each point. :)
So that's it for now. I'll give more details on how the current design looks like in the following posts.

No comments:
Post a Comment