[Glitch toString];

I've been reading around for a while about developing game engines, and the best ways to start one, etc. There unfortunately isn't a whole lot of "best practices" out there that I've found.

Having spent the last 3-4 years in an application development environment, as opposed to more of a research environment, I've grown used to reading what those who have come before me recommend. I probably own all of the game engine design/implementation books that come recommended and while they're all priceless in their own ways they all suffer from the same pattern; the author writes a game engine and walks you through the process.

I've found this to be very helpful when starting sans clue on where to begin. Once you have an idea on where you want to start, and the basic design and components of your engine they become fairly cumbersome. The actual implementations, geometric tests, scene graphs, etc, all remain useful, however the class hierarchies, API, and language specific implementations become a crutch.

I'm currently in the early stages of building my own graphics engine to add to the, currently non-existent, components of my own game engine. While working on it I've found myself, on multiple occasions, thinking "how did the book implement this class?" instead of thinking of the code relationships and deciding on the implementation myself. I think the main reason I'm drawn to look at the book for structure is because of the lack of guidelines amongst the available game development resources I've seen.

I'm a huge fan of books like Scott Meyers' "Effective C++". The reason being that there are a lot of things to keep in mind when implementing something like a graphics engine. Having something like Meyers' book to sit on your desk, or in your bag, to remind you of some little known hurdle and to provide information about a solution would be invaluable.

Seeing as how this is my first true game engine (I don't think my VESA library from '97 counts, nor my basic XNA library) I certainly don't have the experience to come up with anything targeting game engine development of the quality of a Meyers book, but I think I'll be spending some time experimenting, and see what I can come up with.

The current iteration of my engine isn't even crawling yet, but it is being implemented in C++ and OpenGL under OS X. The goal is to make it modular enough that different graphics APIs can be swapped in to support other platforms (DirectX, OpenGL ES, etc.). Which leads us to Item #1,

Item #1: Finalize your graphics engine on one platform before moving to another.

It is very tempting as you start building code to implement your graphics engine to immediately duplicate the work for another platform. The feeling of seeing your first renders happen simultaneously under DirectX and OpenGL is awesome. However, if your engine isn't fully planned out then every time you make a change, you'll have to duplicate those changes for each platform you've started. This can quickly build up, until the bulk of your time is spent updating the code on each platform to keep everything in sync.

By choosing a target OS, and graphics API, you can build a working engine and test out your ideas before you're fully committed to multiple platforms. This will allow you to be more flexible when you do run into a problem or unexpected obstacle.

This unfortunately does not allow you to lazily implement your engine under the constraints of your target OS. The constraints of each platform will need to be understood so that your engine will translate well to the underlying graphics API. Fortunately, most modern graphics APIs follow the same general flow, but knowing the differences between the APIs you want to use will help to lessen any frustration later.

As I plan out my graphics engine, I'll post what I come across and any suggestions that I think might help others out. I won't be posting my implementations, only advice that can help others develop their own engine without the crutch of a known implementation.

Oh, and don't think I'm brushing off books on game engine development. Quite the contrary. Two of my favorite game development books are Eberly's "3D Game Engine Design" and "3D Game Engine Architecture" books. Both of which talk specifically about his Wild Magic game engine. I just think the game development community could use more resources on the Whys, and less on the Hows.

In my last post I mentioned my move to Pi, and since then I've been pretty quiet.. All I can really say is that my move to Pi has been amazingly awesome. Everyone there is cool as hell, and I've really had a blast so far. :)

I have some pretty cool stuff going on, which has kept me busy and I can't wait to be able to talk a bit more about it when the time comes. Until then, I have some plans that, given my recent activities, should come to fruition. I've talked a lot on this blog about starting to actually post technical discussions, and usually something came up to hinder those discussions. Now my work life and my interests are in a nice happy harmony, so I've already made some productivity towards having more valuable content. That's all I'll say, since I'm a master at talking stuff up, but not getting it accomplished. ;) So we'll let my actions speak for themselves.

More to come on that..

In a semi-related note, I've been playing Ninja Gaiden II on and off.. and I must say that it definitely brings me back to the "good old days" when games were insanely difficult to make up for the lack of technology. Something that is missed, until it shows it's ugly head again and causes you to start throwing controllers. All-in-all it's an awesome game though. :) I'm looking forward to beating it this weekend.

I've been working at cPanel for almost 4 years now, and I must say I've enjoyed every moment of it. Ignoring the stress and crunch that is found almost anywhere you go of course.

My co-workers at cPanel are great, and they've really made my stay here really feel like home. However, it is time to move on for me. While I've enjoyed many of the challenges I've faced while helping to design, and implement, the cPanel for Windows product (cPanel Server Suite) I've decided to revisit my beginnings and my reasons for beginning to study computer science in the first place. :)

I've accepted a position at Pi Studios, where I'll be given the opportunity to work with game industry veterans and help bring some kick ass games to gamers around the world.

This really is a dream come true for me, as I've wanted to work in the game industry since playing Quake for the first time.

This blog has been going in that direction for a while now, but hopefully now that I'm going to be immersing myself full-time in game development (yay for not having to 'make time' for it anymore) I should have more steady (and more interesting) new content (and a new design hopefully as well).

On an almost unrelated note, I picked up GTA IV last night. So far, it is the best GTA I've played. I'm so glad it's not placed in the 80s.. and I've been very surprised by the amount of details placed in the game. Like, I swear I heard my car radio make that annoying BzzT BzzT sound prior to my cell phone ringing. :D That makes me happy. Blood splatter makes me happy too. Especially blood splatter on the side of a car, after clipping 3-4 pedestrians after slamming on a very touchy e-brake. Can't wait to play some more. :)

A week or so ago someone asked me if I had any experience with the Streaming SIMD Extensions (SSE). While I often answer the question "What's your favorite programming language?" with "Assembly!", I sadly have never had the opportunity to make use of SSE, nor did I truly know the specifics of the extensions (like, just where I'd use it).

So, to counter this deficiency, I've been poking around learning more and more about them. Which lead me to realize just how out of date my assembly books are. So I did what I normally do when that happens -- I ran to Amazon to correct the problem. Only to find that not only are there very few assembly books published recently, but of the 2-4 books worth getting only one has a decent coverage of SSE (or so it seems..). Most don't seem to cover the floating point unit very well, or x64 at all. Not that it's a huge task to look at the instruction set and figure it out, but if you're writing a book on assembly why not cover topics that modern assembly usage would exploit? I mean one book released in the past 2 years even had a chapter dedicated to TSRs, is that even relevant today?

I can't imagine an author would spend the time writing a book on assembly without covering, x64, floating point, and at least up to SSE 3. SSE 3 has been around since Intel's Pentium 4 Prescott chips, which have been around since 2004. Even that is possibly on the verge of rendering a book out of date very shortly, considering SSE 4 is in C2Ds, and 5 was announced last Aug.

Almost everyone would agree that no one is writing full applications with assembly anymore (at least outside of the embedded worlds), so why wouldn't an assembly book contain the most up to date (read: advanced) material? No one is going to drop out of C/C++ to 'speed up' their code with simple 32bit instructions that their compiler is probably far more skilled at optimizing.

It boggles the mind.

I'm going to pick up the one book that looks decent. I'm also going through Microsoft's info on the Visual C++ SSE intrinsics. So, maybe I'll have some XNA GS vs. Native performance showdowns soon. >:)

Ozone Riders. The upcoming hit from TeamAwesome!™, expected to be released some time this summer, in Paris. ;)

The game has the player orbiting around the Earth fixing the ozone holes, and battling nasty corporate waste disposal drones. Naturally, from a graphics perspective this places a TON of emphasis on the Earth. For an object that will always be in frame, there cannot be any obvious (or slightly obvious) faults with the model, its texturing, or it's lighting. If there are, the player will have to stare at those faults, the entire game.

So, what makes a cool looking Earth? How do we render it in such a way that players will enjoy looking at it? I only have one answer to these questions, and it is, I have no clue. I do however, have some guesses. :)

There are a couple things that when I think of the planet's view from space make me giddy from a visual perspective. One of those things is the atmosphere. That nice blue halo around the planet just screams cool. A visual of the earth from space, without that halo is a fake, I don't care who's stamp of approval is on it. Even an obvious photoshop is better than no halo at all.

The other thing that makes me happy, is detail. From almost every NASA photo I've seen of the planet, you can make out some pretty crazy detail despite the insane distance. I'm talking NASA photos, not NSA photos. So, I don't mean like license plate details, I mean being able to see mountains and terrain detail.

Then, once we add in the fact that our players will be orbiting the Earth, we have to take into account another aspect of the planet and it's relationship to the rest of the solar system. The sun, can only reach one side of the planet at a time. So, as a player, I wouldn't expect for it to be noon in Paris, and Houston. Major point deductions for that.

So (the point of this post), I've been working on the shaders for our planet model for our game. With these things in mind, I thought I'd share the evolution of our planet. :) So without further ado,

A Planet Is Born

Here we have the Earth, fully textured, with a single point light for the "sun". As the sun's light fades a texture is blended in to supply emissive light to mimick the earth's night time look.

Here you can see the night effect a little better.

Here we have the earth, with specular lighting on the oceans and clouds. The clouds slowly rotate over time to create a fairly nice animation. I think this is another important aspect of something like this that will be a major focal point to the game. If an object that is constantly in the center of view doesn't change in some way, it's boring. No matter how beautifully rendered it is, it will get stagnant quick. Something as subtle as clouds moving will give the player minor "oh hey! look at that!" moments. Which add to the cool factor for objects like this.

Finally, this is where I'm at now with the shaders. Here we have the added atmosphere, and normal mapping on the ocean. The effect here is another slow animation that makes the oceans look alive. As you're flying around the planet, the specular light coming off of this adds a whole new level of realism.

I'll probably put up a couple posts next week detailing how the shaders work, along with my new found love for FX Composer 2. :)

On a side note, I've decided what I'm going to do with my "Two week topics". My original plan was to start from the beginning, introduce shaders, and then work up to advanced uses of them. Unfortunately, since this is the first time I've really tried to do a series of articles, I had a huge problem ordering my thoughts enough to work out a game plan for it all. So, while I put that all together (in the background) I'm going to start putting up articles on "middle ground" things like post processing, or like this Earth. Once I get my act together for my original plan, I'll start posting it. :)

Another side note, Go TeamAwesome!! :D