Game Engines, part 4

Physics
Games today require physics. I think it's safe to say that only a handful of genres are safe from this now. But never fear. Although messing with physics has been one of the more difficult things I've done, in many ways it has been the most fun and rewarding. In a 3D environment, humans like to see things move the way they're supposed to, enemies fall and collapse realistically, and objects explode with real-time shrapnel. It's fun to look at, and it changes the way a game is played.

There are a great deal of physics engines out there. This is one field where proprietary, pay-to-use engines practically don't exist. While they're out there, they're not market-domineering like in other fields, and if they are sold, they normally are packaged with a graphics engine. You might have heard of Newton, the engine used in Portal, Half Life 2, Penumbra, and a ton of other physics-oriented games. While not open source, it's free to use as long as you show off the Newton logo on your product. It works in Linux, Mac and Windows.

Of course, you've probably guessed that I don't recommend it. Closed source software is not as "yours" as open source. You cannot modify it or look to see how it works. So I suggest any of many free alternatives: ODE, Bullet, Squirrel, and a billion more. I recommend Bullet. It's being used with the Blender game engine, and is picking up popularity very fast. It's also continuously updated.



Going into physics, I was a bit unsure about one thing. I knew that I had meshes in my program, and they draw to the screen based on their location and the camera's location. I got how that worked. But how was the physics engine supposed to look at the picture? Do I have to use mesh file types that work for both libraries? And how does the physics engine forcefully move objects in my 3D world?

It took me a bit to figure it out on my own, so hopefully this explanation will be helpful. It works like your average kitchen plastic wrap. Say you have a whiffle ball that you wrap up in that stuff; what shape is the wrapping after you've completely enclosed the object? Essentially, it's a sphere. In other words, it is not exactly the same as the object it is covering, but it outlines it. The holes aren't considered, unless you need them to be for some reason.

Because of this, physics bodies are less complex than the meshes they represent. Most physics engines use this trick ( among many others ) to minimize their cost. This is important, because every time you give an object physics you are basically cloning it in the same scene. This can take more memory, but not a whole lot of extra processing. After all, the invisible "wrapping" mesh is not being drawn, not being textured, not being shaded, and it's got significantly fewer polygons than the mesh it's connected to.

For Bullet, every dynamic object has a STATE. That state is its location and rotation. Every time you "step" the scene, which means applying about half a second worth of physics for a frame, or so, those states change. Overload the state class, edit it to contain a link to the mesh object, and have it move the mesh whenever IT moves. Thus, the wrapping tugs its mesh along with it, giving the illusion that the object itself has physics.


Didn't I say it was all an illusion?

Series break: Hex editing fun

I was over at a friend's house a while back, trying to get Ogre3D installed on his computer. Unfortunately, they made an "oops" with the binary package for Windows, and it kept looking for resources on the cd drive. In order to fix it, he opened something I hadn't seen before: a hex editor. In a few simple moves he turned all the "D:/" instances to "C:/" and it was fixed. I was so impressed I decided to try it myself.

I remember being a little kid and playing with Norton Commander in DOS. The program had a file viewer, and if you opened binaries you got gobbity gook. I remember thinking that someone actually programmed in those smiley faces and spades, and thinking "Oh wow, someone is really smart!". Funny thing; as it happens, I wasn't completely wrong.

I've used khexedit for a few small tasks this past week. One of them was to crack the uneditable worlds of an old game/programming tool I used to love called ZZT. I found out that a character on the second line was a '01' in locked games, and a '02' in unlocked games ( or maybe vice versa... anyway... ) Voila! I can edit locked games... or lock one. All on the binary level.

I found this fun, so I turned to script. Unfortunately most text gets compressed, such as with most of the Quest for Glory series and... (sob)... Commander Keen. What's more, on console roms it isn't even proper ASCII sometimes. However, N64 seems to be the simplest text to access, and of all the N64 games they picked the best one to make easy:


The text in Ocarina of Time is completely uncompressed. It's out of order, but its in plain text ( to a hex editor ). It's also possible to color sections using specific symbols, as above. I'm decoding it slowly. The important thing is that any unused space stays unused, so you have to use text that fills in the space as exactly as possible. I'm still not sure if I can control the creations of new lines and things like that, but I haven't spent much time with it.

I'd like to fiddle with FF7. Some people have been able to remake entire scenes in the game, changing characters, creating new dialogue, and so forth. I'm not clear whether they're using a ROM or the PC version, but I'm hoping its the former since I am using linux here. If anyone knows anything about this, please drop me a line.

This isn't really something I'd say is teaching me much, it's really just kind of fun. But you never know what you can learn doing weird things like this. Certainly teaches you a bit about security, and how binary gets read.

Guess this is another case of me going "Hmm, what can I discover in this cave?" and poking my head in.

Game engines, part 3.

The API

I am not making this blog into a tutorial for one library or another. Blogs aren't really good for that. Since you're here reading on your own accord, I think you have the will and ability to teach yourself anything. There's plenty of tutorial documentation out there, anyway. What I'm offering in this series is more of a stepping stone - an understanding of the mindset you need to quickly and efficiently conquer the library of your choice.

You have the tools. A brain. Community. But there's something else that's equally useful in becoming self-taught; three letters that every programmer should know: API. Indeed, if you intend to use ANY library, whether for games or for any other project you can imagine, then you'll need to become familiar with this term. It's a bit of a strange, ambiguous acronym, but also very simple.

An API is simply the interface for programming with a library, or anything else. It stands for "Application Programming Interface". It is the vocabulary of what you want to program with. For example: in Allegro, "blit" is the function you use to draw an image on the screen. Just now, I am talking about Allegro's API. Turns out you can also use draw_sprite, and the arguments get reversed when you do ( which is ugly, I believe they're fixing that in the newer versions. ) So now I'm discussing problems with the API. That's a subject that gets talked about a lot, for any library.

A lot of different libraries use very similar APIs, to make migration easier. Ogre3D and Irrlicht, for example, both work the same way:

1. Every object in a Scene is a Node.
2. The Scene Manager controls Nodes.
3. Programmer directly controls Scene Manager

Because they share these similarities, it is easier to jump from one library to the other. They aren't usually exactly the same, however. If you want to use two libraries together, it's best that they use slightly different APIs, or at least enclose the similarities in different namespaces. But they're close enough.

The API is not normally something you have to just up and learn, nor are you required to go in and figure it out by reading the source code. There are programs such as Doxygen which go through source code and efficiantly document the API into web pages. This is almost always done. In fact, here's Ogre3D's:

http://www.ogre3d.org/docs/api/html/

This is a huge library, so it gets an equally huge API. But using the API, you can quickly figure things out. For example:

Q: How do I rotate a 3D object?

A: Well, its basic knowledge that all 3D meshes are attached to Node objects. So what you must rotate is a Node. In the Ogre API, click 'classes' at the top. Under 'N' is Node(Ogre), which means the Node class in namespace Ogre. Click 'Node'

Presto, all the methods you can call on a node object. And only a few pages down, or if you do a find for Rotate, there's yaw, roll, pitch, and two (complicated ) rotate methods. They also show you what arguments they need! Don't know what an argument means? Click it. And if you click on the method name itself, it jumps down to the special comments from the source code in a neat blue box. Very organized, isn't it?

The Allegro API is especially nice. You can download it as a .chm file ( Windows help, but Linux can view it too ), or you can view it online. Allegro has a really solid, easy to read API, with lots of description, and a comfortable theme. You hardly need to look at another tutorial.

There are some languages that are too young to have a great API. If you chose to work with Gosu, you'll have some trouble. Their API is more a series of tutorials, but if you work with Ruby, someone threw one for you together on the Wiki. Thats a good example of why you want to pick a library that favors your particular programming language - stinks to be an odd one out, when you're looking for help. But Gosu's also easy enough that you hardly need references.


The point of all this is that when you're looking into a library you might want to use, go first to its API. You are often tempted to start by looking for a tutorial. Don't do that. There are always tutorials, but APIs that are neat and well documented are vastly superior. Besides, one person's way of coding might just make you more confused ( though there's nothing wrong with looking ).

API Links to look at:

Allegro

Ogre3D

Irrlicht

JMonkey Engine


I suggest you peek at all these links for examples :)

3D ( And 2D ) Game Engines, Part 2

What is true of all game engines?

1. The more you understand simple geometry and graphing, the better. Coordinate systems are the way to present things to the human eye. This should be pretty obvious, but as you go from novice to pro, you'll quickly learn that there are things about your own perception that you never noticed.

2. Collisions and physics always use the same basic principles. As a matter of fact, advanced physics libraries such as Bullet and Newton ( ala Portal ) can be just as beautifully applied to 2-D as 3-D. One big difference is that in 2D, you can get away with collision using rectangles more easily, or even do a check on pixel overlapping.

3. Everything is an illusion. There is no physical space occupied by the hero of your game. Consequently, you will need to use a number of tricks that don't really fit reality. In 3D, we use a system called "Paging" to erase polygons that are hidden behind other polygons, so that the system has to do less work. There are also texture tricks that make it appear as if surfaces are reflecting ( called "environment mapping" ) when they're actually doing very little work. 2D has its own set of eye tricks.

4. You must care about your resources. This relates to the paging concept in 3. If you've only worked with text based applications, you're probably used to being able to do whatever you want. With even the most basic 2D graphics, however, this is not so. You have to watch your memory usage, only load what's needed, unload what you're done with, and above all, have a solid data structure to manage these operations.

3D Game Engines, part 1

While I was in college, I worked ahead of my classes with a 2D graphics library called Allegro. After I graduated, I proceeded to work with SDL, Gosu, Irrlicht, and Ogre3D (in that order. ) Any field of computer science is an unending journey of learning, but I would still consider myself enough of an authority on graphics engines to write on the subject. In fact, that's why my friend Matt suggested that I start this blog.

This will be part 1 of a series, as there's a lot of ground to cover and I want to be detailed. I want to teach the aspects of this subject that slowed me down, so that other programmers won't have to muddle through it like I did.

For part 1, I'm just going to go over all of the engines I've fiddled with and describe them to you, so that you can decide what you want to mess with. This won't help much in terms of use, but it will allow you to pick a starting place and give you time to get familiar with its community. If you've never installed a library before, I suggest asking google since that's a fairly lengthy subject, but it generally goes something like this:

Step 1: In Windows, download/install the SDK. In Linux, compile the source code, or look for a package ( for example, in Ubuntu a lot of libraries are in the repositories, all you have to do is apt-get install the one you want! ) Sometimes you have to compile source in Windows, too. Don't worry, it's not that hard, and you have more control over the result. I always reccomend doing the compiling if you can, but if you're an absolute beginner you can pick something with a package or SDK.

Step 2: Link to it. A library is compiled ( or packaged that way ) not because its a program, but because all of its source code does NOT need to be compiled over and over every time you want to test your program. You just link to it. This speeds up development significantly. You usually link to one or more dll or object files, which is either placed in your system's path ( /windows/system32 or /usr/lib ) or in the folder of your project. Actually, you can put it anywhere, as long as your project can find it! Most IDEs, for example, CodeBlocks, are good about setting up directories. Just go to the build option and pick where you stashed your object files. Again, this is not required if you have it in your path.

Step 3: Include the headers. The rules are the same. The headers will be in a folder somewhere, and they tell the program what the API (syntax) of the library is. These have to be found by the compiler too. Like the binary, this can either be via the system path, or a preferred location.

And that's all, you just have to include the headers you need into your project and it should work. Each library has its own documentation for how to do this.


Without further ado, The libraries!

---

Click the name for a link to the official website

ALLEGRO: Allegro is programmed in C, but it's pretty high level. It does have a few globals, but it wraps well in C++ if you intend on using classes. All of this aside, Allegro is a fantastic library that is made to be easy and fun. It's mostly 2D, but very fast and very high quality. http://www.allegro.cc shows just how many wonderful projects have been made in it. Some of them are extremely impressive!
Please note that this library has recently undergone some serious renovations, so if you get the latest version, it will be a totally different library from the one I've been using. I reccomend it though, because it's more standardized and simpler to read.

SDL: It's faster than Allegro, and uses OpenGL, but it's harder. It doesn't come with a lot of easy functions like flipping and rotating, filling, drawing primitives, and so forth. There are modular libraries that can be added to SDL to make it do these things, but they dont come bundled. SDL does have a lot of documentation, and using it will teach you more about 2D than Allegro will, since Allegro does the work for you. SDL has been used commercially quite a bit. It's a C library, like Allegro.

Gosu: Easy as it gets. Gosu is designed to be very strict in form, simple, and elegant. Development in Gosu is FAST. I had a whole engine working from scratch in under 3 days. The downside is that it hides everything for you. You can't, for example, directly alter loaded images. So if you want to animate an explosion within the program, you're out of luck - you'll have to do that as a little animation that gets imported. This isn't usually an issue.
Gosu is C++ all the way, and forces the use of Boost pointers, so to use this library you'll need to get Boost too. But this is a good thing; boost pointers delete themselves! No memory leaks :) And it's going to be added to the C++ standard eventually anyway, so it wouldn't be a bad idea to learn how Boost works.

Irrlicht: My first 3D graphics engine. Actually, my first was CrystalSpace, but that one is way too complicated to start with. Irrlicht, however, is the easiest I've messed with. It has built in collision detection, physics, and shadow effects. However, it's buggy. The stencil shadows have a lot of issues that are still needing correction. On some ATI linux machines they flicker wildly. It's also just not very powerful, and doesn't offer you as many options as the next library. But for beginners, that may be a good thing. Irrlicht is C++.

Ogre3D: This is what I finally decided upon. Ogre3D is easy, powerful, flexible, and MASSIVE. As an example, Irrlicht has just one shadow type, but Ogre3D has six. It is also made to be modular. It does not come with physics, or collision detection, or anything like that, but the massive community has contributed code that lets you link it up easily with other libraries. Ogre3D also comes with a sample framework that lets you jump right into programming a scene without any setup, all in a single function. Used in conjunction with the tutorials on the website, this is quite powerful. Also C++


If you're a Java user, look into JMonkey. If you prefer python, Disney's Panda3D is your weapon of choice. And I should mention, if you're a fan of Ruby, most of the Gosu community uses that instead of C++ ( but there's support for both ).

---

This should help you get started. Using this information and a little google-fu, you should be able to pick a library and set it up fairly easily. I'll be writing on Allegro and Ogre3D, since those encompass the 2D and 3D programming provided in the list. If you choose something else, you should be able to apply anything I say. Libraries aren't all that different, really.

Anyway, good luck, and see you next time!

And so it starts...

Before I became passionate about computers, I was a writer ( and I suppose I still am ). As such, I've had a lot of experience with blogging, but it's always been personal; a hodge-podge of poetry, politics, and other mundane matters. Then a friend of mine, also a geek, suggested that I begin a blog that shares some of my self-taught programming knowledge. It's a bit more accessible, and it's something I've flirted with doing for some time. So I'm doing it.

This is my geek blog. Here, I will give out programming tips, source code, discoveries, opinions in the field ( of which I have many ), and so forth. I'm a Linux user, so there will be an open source slant to all of this, but I do believe in reaching across the aisle with cross-platform programming and the like. I also do like games, though I'm a tad behind ( I'm playing FF7 on an emulator currently ). I will occasionally do a game review if something impresses me.

Last, I may discuss music now and then as I'm a huge J-Rock fan ( Japanese rock, in case you don't know what I'm talking about ). I can see a lot of my friends rolling their eyes at my irrepressible fandom, but this ~is~ a geek blog, and J-Rock is pretty damn geeky. My free time is a fairly simple rotation of fancies: J-Rock, Games, Programming, J-Rock, Games, Programming, J-Rock... etc. And a little bit of internet fun on the side.

So a bit about myself.

I'm Joseph Austin, and I live in Nashville, TN. Great people here, but also ass-hats. And no jobs. I'm a recent college graduate and I'm feeling the heat of this ruined economy. I have yet another interview next week, but even so I'm getting up early tomorrow to go apply at another ten places. Hurry up and fix things, Obama, hit the undo button!

I like to program, and my dream is to do games. Thats the cute fantasy of a lot of would-be programmers, but the difference is that I actually like to code. To me, programming games would be the ultimate mix of creative story telling and pure geekiness - a convergence of my two main personalities. I grew up on Adventure games, where stories and puzzles helped hammer logic into my brain. I discovered early that no medium could draw me into a plot like one where I'm the hero, and I still have yet to lose that feeling. I want to one day create a universe so exciting, original and interesting that it actually inspires players, the way games like Gabriel Knight and Final Fantasy does for me.

I have a website: http://www.vasilisagames.com

There's a game on it, but it's REALLY old. I'm touching up the source a bit, but it's filthy. I was still in school when I wrote it. I can't wait to upload some good code, and I have some moderately good stuff almost ready for launch. The date for release on my latest project was for Saturday, but I got sick a week and a half, so I'm extending it. I'll be posting that on the site soon, maybe tomorrow.

Well, that's all I have to say for now. I'll be thinking about what to write tomorrow :)