Strange Aeons

There really is something to be said about reinventing the wheel.

It seems that every time a new game engine is created, it’s just recreating the same basic code that all the other engines already do. However, in my current project, it’s not a FPS, nor anything using fast camera movement most of the time.

A new engine was needed, one designed for a mostly static, but highly detailed scene. And it’s working out well. Normal game engines do not need to do mouse picking that converts to texture UV coordinates. I’m guessing that would have been a *severe* pain with someone else’s engine.

the argument

Here it is – the argument i had with a good friend. Let’s see if it makes more sense in text.

What started it: we’re watching a game of Poker. My initial statement: “I think it’s cheating that people can use a hat and glasses to hide themselves while playing Poker. That’s why I like computer games – when done right, the rules are the same for the player and the computer.”

My friend came up with this point (paraphrased): “No matter what you do, a computer player will never be on the same level as a human player, and therefore will always cheat by your definition.”

Background: I’m a game developer. I have strong feelings about how games should be designed. As an example, my game library for PS2 consists of about 10 games. Yes, that is all, despite all the possible games out there. And some of those are from series. Now not about to say that’s *all* that’s good. Just that there are relatively few that get it right.

I agree with part of his statement: computers and humans are never going to match abilities. He was maintaining that the humans would be better most of the time, while I felt the puters would have better, more accurate reactions, but either way, we agree on the point. What I don’t agree with is that the computer will always cheat.

When writing a computer player, you really do have the option of choosing what level of integration the player has with the mechanics of the game. Because the game world is effectively open and available to the computer player, it is literally possible for the computer player to make anything it wants happen.

Therefore, to create fairness, you must create an artificial bottleneck. A place where a computer player can ‘see’ the same things as a human player, and ‘react’ by sending input back to the game. Personally I prefer to keep it as close to the controls as possible (whether it be gamepad, steering wheel, or wii-remote). This way the computer player is limited in exactly the same ways as a human player is.

My friend’s response was something like, “But if you have two characters with different abilities, like one can fly and the other cannot, is that not innately cheating?” Sounds plausible. Here is why I disagree: it is only cheating if the human were to choose the same character as the computer, but not be able to make every move the computer can make.

This all comes down to the level playing field concept: if all things are equal, then the human and the computer should have an equal bottleneck to do the same task. This is not to say that the computer cannot be better at making the bottleneck do what it wants. This is the entire point of games – that different human players have different abilities at persuading the bottleneck to do what they desire. It just means that as long as the bottleneck is consistent for human and computer players, then it is not cheating.

Our real world has it’s own bottlenecks built-in: we typically call them “physics.” And in most any real-world game, it is considered cheating to get around the bottlenecks. Therefore, to wear hats and glasses should be considered cheating, unless *everyone* is wearing hats and glasses.

And I don’t like wearing hats and glasses.

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.

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!

Links LS 2000 (Macintosh Port)

2k Gameplay Screenshot

  • Full Name: Links LS 2000
  • Original Developer: Access Software
  • Original Publisher: Microsoft
  • Original Release Date: 2000
  • Port Comissioned by: Green Dragon Creations, Inc.
  • Mac Release Date: 2000
  • Mac Publisher: MacSoft

Excerpt from Mac version review at Mac News Network

Links LS 2000 is a revamped Macintosh version of one of the premiere golf games available for Windows, offering gamers one of the most beautiful and realistic golf simulators available for any computer platform.

Links LS 2000 features several modes of play scattered across the game's six beautiful courses that have been modeled after their real life counterparts. Every detail, from sand trap location to the green, has been accounted for. Video-captured players, including Arnold Palmer and Fuzzy Zoeller, contribute to the realism of the game, although the static, pixelated crowds do little to complement the life-like players.

I came in on the tail end of the project, and it was a short one for me. This product was based on
the earlier version, the original Links LS, that I had helped port. By the time I got involved,
all that was needed was bugfixing. With my familiarity with the original code I was able to get
things on track pretty quickly. However, this was another reminder of how important unit testing
is to compare both platforms together.