Bridge Jobs

While I'm not working on a bridge..well not literally..I did recieve some good news today: I am becoming a peer tutor for Software Architecture! My teacher Nick Penney sent me an email earlier today and asked me to join up. While the pay is decent but the hours are very flimsy, being tutor is worth its weight in gold by helping reinforce concepts and being on my resume. So I'll post more on that as it develops.

As for the Bridge...while being a rather complicated design pattern, I think I just built my first incarnation of it for my side project. In our Structure of Game Design (SGD) class, we recieved a nice set of wrappers for DirectX for basic sprite operations. Its pretty solid and will make our project in class go much faster. On my side of things, I have been working on a Collision/Physics system which I dubbed the Simple Game Engine (SGE). A while back, I read that it was a good idea that your game code is as API independent as possible. I went back and redid the SGE to be that way and so far it has served me well going between Allegro, Win32, and DX. However, the wrappers presented a problem that I ran into when I moved the SGE between different APIs...the code developed for the API inevitably became linked in some fashion with API so the code written (that is code developed outside of the SGE) was not usable in another project.

If your still following, I found a solution to the problem. I developed a series of interfaces that are fairly generic that cover Rendering, Resources, Sound, and Input. These interfaces are very basic and are the only things that SGE objects will use. However, a new class in the SGE (CEngine) now maintains ptrs to the implementations which are specified at runtime. I created a few implementations that are derived from the interfaces. Each one is specific to using the SGD code provided.

So now I have broken my game code into three parts: The SGE dll, the Game dll, and the DX exe.

The DX exe brings the other dlls and create an instance of the game from the Game dll. The DX exe also intializes the CEngine with the specific implementations. The Game dll then uses those implementations to render/get input/ etc. So now I have three projects that can be modified independently and the game code built for this project will not be linked to the DX code.

I initially did not intend to create the middle layer of the Game dll but it evolved naturally and I now thrilled that it worked! When I started the SGE, I began to use it as an excuse to try out different programming techniques and with this recent development, I am extremely thrilled. This is going to be a good month.