Today, I'm going to introduce the coming series of articles. I'm building a game engine and I'm going to talk about the steps that'll be taken and discuss the choices that'll be made in order to achieve this mission. There are tons of well designed open source game engines out there. I'm fully aware of that but as far as I know, game programming and embedded systems programming are the cutting-edge of both design and performance on the field. So, I've just decided to take the challenge.
We're gonna baptize this engine YAGE. I bet some of you geeks have already figured it out. Yes sir! YAGE simply stands for Yet Another Game Engine. For those who mis-guessed awful stuff: YAGE has *ABSOLUTELY* nothing to do with ayahuasca!
Alright! Before you dive in, you should be more or less familiar with C++ and OO paradigm and that includes particularly but not exclusively using pointers, references, inheritance, polymorphism, templates, etc. Knowledge in XML and design patterns will be helpful too.
1. What are we gonna make?
I'm not done with the architecture yet. We may discuss how the engine should be designed for the next ten weeks without getting close to the ultimate disadvantage-free design. Instead of that, we're gonna start by the core functionalities and utilities; and the engine should turn to his final shape as we commit ourselves to new features and requirements.
As for the requirements, there are the basic ones:
- simple OO design
- data and logic must be separated
- the engine must be easy to tune
- loose coupling and strong cohesion
To ensure the first 2 points, we're gonna use C++ and XML and, with wise use of these languages, we can manage to reach the 2 last requirements.
The general purpose core functionalities that every C++ game engine maker should be thinking of may include:
- memory management
- logging and debugging mechanism
- error and exception handling
- serialization
- resource management (including game engine settings)
- few design pattern templates
2. How are we gonna proceed?
I'm gonna work under a Linux environment with GNU tools namely gedit to edit code and make and g++ to build the engine. I'm not telling you I'm a hardcore masochist programmer it's just that I got used to the console. Feel free to use your own tools as long as you have a tight grip of it. I'm gonna keep the code as platform free as possible and I'm gonna selfishly assume that you're able to resolve the incompatibilities on your own. If you opt for the same toolchain and methodology as me, the next section may interest you, otherwise just jump to the last two lines.
2.1. Tune up gedit
I use gedit to edit and I use a couple of plugins to make life easy. The default set of plugins that comes with the editor is not good enough, you should at least install the gedit-plugins package to start using useful features.
In gedit, under Edit -> Preferences.
In View tab, I have the options checked as the following:
In the Editor tab, it goes like this:
There are some good plugins worth the try, namely:
- Auto Completion Plugin
- Bookmarks
- Bracket Completion
- Class Browser
- Code comment
- File Browser Pane
- Session Saver
Check them all, pick the good ones and use them wisely. Without these babies, it'd be better to roll back to the good old vi and quit the GUI for good.
2.2. Make and Run
Makefile and g++ won't be covered in this article. We've seen too much for an introduction. Therefore, I'll give you a couple of links for exhaustive material on these tools, perhaps you should google a quick cheat sheet.
GNU Make
GCC and g++
Just go ahead and pick a good tutorial if you think it'll be of any help.
Conclusion
Okay! that's a nice introduction.
In the next article, we'll try to figure out a memory management mechanism for our engine.
No comments:
Post a Comment