Why windows cross development can be a pain.

Debug image crashes app, have to compact them on mac side.

Can’t switch to window mode – no button. Compact again on mac side.

Network disconnects halfway into session. Have to reboot.

Windows UAC locks up when switching back to window mode.

Took two minutes to fix, once I could actually reach the problem. Total time: two hours.

Done!

My first iPhone project, Flick NBA Basketball, now shipping! View on Freeverse.com (dead link)

My goodness it’s fun to work on the iPhone. It’s amusing to me, that my career started with Apple ][e’s and the iPhones are based on the same basic architecture (ARM processors). It also seems to separate the coders who actually care about resource (RAM, disk, etc) useage from the ones who just “splat” code.

 

Yup, there I is, “Lead Programmer.” Woo!

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.