(Part 2: “Searching for answers”)
In the previous post, I told you the whys and wherefores of my idea to write a game engine. I cobbled together a mission, a philosophy and a general approach. The general approach I went with was to find a bunch of awesome libraries and pull them together to make my game engine, so I then trotted off to Google to do some searching.
Let’s take a look…
All games need something to look at, and that means we’ll be needing some awesome graphics, so top of the library list for me was rendering.
I’d already decided that my engine will be a 3D engine, so I set about finding some 3D libraries. After a bit of time with the search engine, and quite a lot of reading, I eventually boiled the choices down to my two main contenders:
As far as I can tell, these are both excellent libraries and would both do what I needed them to and WAY more besides, but I needed to make a choice. When it came down to it, it wasn’t the library itself that won me over, or any technical details, as to my largely untrained eye they both look excellent. Rather it was the wealth of examples, documentation and the large active community of Ogre3D that won out.
OK, now I have a library that will help me render some super cool stuff on screen. The next thing I decided as important was a way to interact with the game.
First off, yes, that’s a Short Circuit reference, and yes, it’s completely predictable and not at all witty, but I HAD to. Moving on…
With this library choice, I was really quite lazy. Whilst searching about for the rendering library, I looked through a few Ogre tutorials and examples. There are ready made examples out there of an input system that works well with Ogre — OIS. It seems to do all I want from an input library — it reads input, so that was that. NEXT.
Is it logical?
Moving on, I figured that we’ll be needing a bit of logic. At this point, I don’t have a particular game in mind to be written with the engine. In fact, I don’t even really have an example in mind to be written in the engine! Consequently I have no clue what the logic would be. More to the point, I don’t see that a game engine would have any logic at all — surely it’s just the game that has logic? This line of thought led me to the conclusion that for a game engine, maybe “logic” and “scripting” are the same thing. I went with this thought and started to turn my attention to a scripting solution.
There are tons of scripting languages out there, and some that are really well suited to a game engine. The truth on this matter though, is that I’d pretty much already made up my mind as soon as I thought of scripting. For my scripting language I’d be using mono.
There are some very good technical reasons for using mono as your scripting language, things like:
The code is compiled to bytecode so isn’t completely interpreted each time it’s run.
That standard libraries are very extensive, and very powerful.
There’s tons of third libraries available.
It’s reasonable simple to integrate.
The main reasons I’d already chosen mono though are:
I know C# well
The team knows C# well
Can I get a Boost?
As far as I was concerned, that was pretty much all I’d need in the way of libraries to get something really really basic started. The only other choice of library/libraries that I thought would help was something general purpose. As I’ll be writing the game engine in C++, I wanted something to help out with all those other every day coding tasks which I have no desire to rewrite for the nth time. Boost is a series of C++ libraries that is truly excellent and just makes it way easier to get stuff done.
I write some actual code, and get a 3D thing showing.