README.txt

Had a mock-argument with a good friend over something very dear to me and my work. Realized that I couldn’t get my point across.

My job requires that I can get my point across. I’ve been working so hard that my ability to communicate seems to have suffered. Up to now I’ve avoided jumping on the blog-wagon, as anyone who I wanted to know what was going on with me, already did.

This is a training excercise. Comments are welcomed, to see if my points are getting across.

theComplex (Game Engine)

12995043

  • Product description: Game engine with a core concept of “most geometry will stay onscreen next frame too.”
  • Product history/genesis: Freeverse approached me about making a game engine that could run on both Mac and Windows platforms for a game series they were pitching. The games were ideal for the style of engine I already had in mind. The Hoyle games were completed after successfully creating an engine capable of driving DirectX or OpenGL. Soon after, iPhone became big and in less than a week theComplex was running on iPhone too.
  • Team: Self
  • Core Technologies:
    • C++ for Games, inside a cross platform wrapper
    • Objective C in Cocoa for Mac OS X wrapper
    • Objective C in UIKit for iPhone wrapper
    • C++ for Windows wrapper
    • Java for Android wrapper
  • Most proud of: This engine shipped in many games, and was updated and added to many times over the years. But throughout it has remained stable, well documented, and efficient.
  • Responsibilities: Everything from design to implementation

Custom Basketballs Screenshot

The design of this engine was based on years of experience with debugging other people’s engines in ports of Windows games to Mac. In each engine, when a new frame was started, everything from the previous frame was destroyed. All the sorted lists, all preprocessing, always redone every frame. In theComplex, the entire list of things to render is kept every frame. This way the game can choose to re-sort as often or as little as it wishes.

Falling Coins Screenshot

When Freeverse was purchased by ngmoco:), they chose to go a different direction with our technology choices to an internally designed javascript engine. Ngmoco:) invited me to help design and implement the 3d component of their new engine. It was never used in a shipping game because the core javascript engine simply could not keep up with the requirements of 3d engines. Two years later they have finally allowed alternate engines, and are now using Unity3D. As it turns out, Unity is so similar in design to my own engine that it was more like “coming home.” Even though Unity does not have the 2D support, some of their additions are brilliant.

About Me

I typically end up dealing with all the junk most projects don’t think about until a week before release and they realize that not all devices act the same, and we can’t fit the game into the 100mb limit.

I am a twenty year game developer veteran. From humble beginnings as a shepard I rounded out my skills in application development, eventually building a business porting games from Windows to Mac the hard way. Working in mobile game development for many years with my own engine, working with Unity3d felt like coming home.

Major facets of my life: God, Family, Work. (Isn’t everyone’s?)

Despite non-religious parents, somehow as a teenager I learned God existed. Later my wife helped me understand that He got me through the hard times. Now I do my best to be a disciple of Jesus.

When we met, we were just gonna stay friends forever. No kids, just have a lot of fun together.
Fifteen years later we have been happily married for over a decade and absolutely love our three kids.

Coding since 1993 on an Apple ][e, and most of my career has been in games. I’ve proven myself capable in all levels of development from the lowest to highest levels of design and implementation.

Few years ago a couple good friends went to motorcycle riding school, and wifey said I could go. My father was big into it, and now I ride as often as I can… when the kids go to bed! :^)

Interested in working with me? Check out my portfolio, or drop me a line!

Massive Assault (Macintosh Port)

Ice Planet Screenshot

  • Full Name: Massive Assault
  • Original Developer: Wargaming.net
  • Original Publisher: Multiple publishers, depending on region
  • Original Release Date: 2003
  • Port Comissioned by: Virtual Programming Ltd.
  • Mac Release Date: 2004
  • Mac Publisher: Virtual Programming Ltd.

Excerpt from the USA press release…

Red Planet Battle Screenshot

Massive Assault is a fully 3D turn-based strategy game set in a futuristic world of, missiles, mechs, and mayhem. With 26 different land, sea and air units, huge 3D landscapes and 6 different planets on which to battle, Massive Assault is a strategy gamer's dream.

With Massive Assault you can play against the top-notch AI, or with your friends via hot-seat or over the internet. The game combines the best elements of turn-based war gaming with a unique "secret ally" political feature that can disrupt even the best laid battle plan.

Desert Battle Screenshot
After years of doing totally different, non-game related work, this was the first foray back
into game development. There was a lot of catching up to do.

At first we were going to use an existing DirectX compatibility layer. As it turned out,
it did not have all the necessary parts to run a game with these abilities. This game uses all
the latest stuff, including vertex and pixel shaders, which were not available with the
software we were going to use.

So we set about the task of writing our own compatibility layer from scratch. We chose this
direction for two reasons: we could maintain the code ourselves, adding what is needed;
and it would be based on Cocoa, being in line with the "New-Mac" way of doing things.
It is the direction Apple wants to go, and as it turned out, we have found it very easy to
work with.

Shadows and Highlights Screenshot
In all honesty, it really didn't take that long. Well, not in project terms of time, anyway.
As it turned out it was not the DirectX
layer that cost us time – it was the vertex shaders. We converted them to use the standard
OpenGL ARB vertex programs, in a naive fashion. They worked on the ATI video boards immediately.
Unfortunately the NVIDIA video boards were driven crazy by them. Kudos to all at NVIDIA
and Apple who helped us figure out what the real problem was. At the time ID Software's
Doom III was on the horizon, and was pro-ported to use the same type of vertex and pixel shaders
this game did. I commented "Unless you fix this, ID software is going to look at the
Macs and laugh." As it turned out, Apple and NVIDIA did their jobs, and six months later
there was an OS update to the OpenGL drivers that included a fix for the problems we saw.
Somewhere in a readme I think, it mentioned that it fixed problems for Doom III. Did I call it
or what!

Reflective Water Screenshot
This was a great experience. The DirectX compatibility layer is working wonderfully –
we can now port simple projects in one hour! While this is only good for tutorials
and such, it is actually quite useful to us. We make sure
additions to the engine work the same as the original PC. We take demonstration programs
written for the PC and port them, and fix the engine to make them match.
And each successive project has used this layer and improved upon it.
This was the best idea we ever had!