Steam really blows

Wow. I never thought a company like Valve would so completely jump the shark, but I personally believe they have with Steam.

I've got nothing against online delivery methods. I don't even think I'd mind the occasional online authentication system. But the fact that Valve has decided that Steam is their sandbox and I have to ask permission from Steam to play with any of my toys I've might have left there - ever - is ridiculous.

Compare this - I installed UT2004. I got the ECE DVD because I had lost my older DVD after my last move. I put in one disc, I put in a installation path, a few minutes later I'm trying out Frag.Ops. That's the way an installation is supposed to work.

Valve, who decided not to release a DVD version of Half-Life 2, has me installing five CDs in succession starting with Steam. Then Steam asks to connect to itself, and it does. And then Steam updates itself, and it succeeds. Then it asks for my username and password, which I give.

And then Steam dies. Or lost a frontal lobe, making it impossible to talk to itself anymore. Any attempt to run Steam or play Half-Life 2 says that Steam isn't up and running and to go check the status page (which says that it's running).

Did I install Half-Life 2? Yes.
Did I install Steam? Yes.
Is Steam able to talk to the network? Yes.

And yet, I can't play the game I've only had since Christmas. That's pretty sad. In overextending their design of Steam to be this all-reaching all-powerful coordinator of information, Valve introduced a single point of failure. And when that fails, you might as well pour concrete on your sandbox.

I'm reasonably sure it's some conflict between the earlier install and this one - but Steam won't tell me. Nor will it help me work around it. I might be so inclined to 100% wipe everything Valve off my drive, because then a completely fresh install might work. But I also might just wipe everything Valve off my drive and tell them to go stuff themselves.

For the curious, this isn't the first time I've had problems running Valve's software...

I'd love to do a GITS game

I'm catching up on my anime lately and am generally watching Ghost in the Shell: Stand Alone Complex and .Hack. I'm not sure when this episode of GITS originally aired, but most of the story centered around the team seriously kicking ass on a huge oil platform.

GITS is one of those licenses that I cringe when I hear a game about it, because I know it's probably just going to be cookie cutter nonsense. Stand Alone Complex really provides a solid ground for a game. It's got breadth and isn't overly weighed down in the science fiction nuances of brain-hacking and the like which, while I loved in GITS 2, is difficult to translate into a gaming experience properly.

If someone were to make a GITS squad based tactical game, where you had specific missions to play out and you had to direct the various members to accomplish it - I'd so pick that up. Turn based would work well, I think - it would let you combine some of the "hacking" aspects with the tactical. While you have the Major and Batu trying to break into a building, the hacker in the airplane could be trying to open doors and get info.

Hamster Wheel

For those familiar with my rodent problem, you'll appreciate the fact that now that I have my box back up and running - I almost regret it. Currently I've taken the Unreal Engine, ripped apart it's basic concept of how players control actors in the game, spliced it back into the illusion of a single player taking turns against the computer and placed within a framework capable of creating missions, forming squads and even faking e-mails from fictional co-workers.

And now I just want to hit my head against the monitor. While definately past that other crisis which spawned this turn-based framework in the first place, now I've got minutia to deal. And really important minutia.

For instance - my biggest AI problem right now deals with landscapes and line of sight. Normally in Unreal, bots know where than can go via previously established and non-mutable nodes. In the UDS framework, those nodes can't exist because the whole map is random. So the code which makes these AI choices is attempting to sniff around to find a decent path between the enemy and it's chosen target. It succeeds approximately 70% of the time, but another 30% is spent needlessly taking turns or attempting to climb trees.

Now, I could easily solve this problem by removing the random terrain. Without terrain, I know that the spot where the enemy is trying to go should be in sight, and if not then there is likely some kind of problem. When I've put a hill in the way, however, I can't make that assumption. I've got this actor called a SkyKing which floats around and helps the code "see" over hills, but it's still having problems detecting obstacles in the path.

Course the problem is that I've grown to think that the random terrain is beneficial to selling some immersion for the game. Turn based play is hard enough without having every map as flat as a pancake. So now I have to weight that benefit versus the technical problem it causes.

It's usually this kind of minutia that can drag out and potentially suffocate the whole project. I think at this point I have too much invested to actually walk away, but I also know this won't be the last of it. This is that odd point where a tech demo has to actually try to be a game - and I'm much better at the former than the latter.

Computer Woe, Part Deux

Well, the trojan reared it's ugly head again and started to try and stomp all over Tokyo ... and by Tokyo I mean all nearby internet addresses. Tiny Firewall gave it the smackdown, but I just didn't want to fuss with it anymore. A reinstalled C drive now means no virus, much better system performance and a whole lot of re-installing to do. Not as bad as it sounds, I've got four partitions so it's not like I lost much.

I will have to pick up a new version of UT2004 though, since my CDKey was stupidly lost. Oh, and I have to coax my DVD drive back to life. Oh, the humanity.

A simple demand

I was plotting my evil Mini plans and realized that that the Tapwave would be an excellent remote device for the it. It would be like a joystick and a VMU rolled into one, like playing the GameCube with a GameBoy.

Sadly, Tapwave doesn't make the Zodiac to work with OSX. Would take some hackery.

Robert Frost

Mac Mini Game Console

I was surprised to see this article on uses of a Mac Mini completely leave out the notion of hooking it up to a TV as a gaming platform. Several blogs and forums have mentioned it, although most dismiss it when trying to compare it directly to current gen consoles. So let me take another stab at selling it.

But before rattling off some steps to making such a platform - let's remember ... the goal wouldn't be to make a device which would stampede all over the next gen Sony or Nintendo AmazingBox 3000. That's just not possible - those are specific devices with subsidized hardware intended to glut an entertainment market for years. You can't beat that game without playing the game by their rules, and nobody we know has the money to do that.

The goal would be to make a unit which still had respectable power for this generation that was easily accessible and modifiable by a community. If you consider that there is still a community homebrewing games for the Dreamcast, you could see where the demographic exists for this.

This wouldn't be about trying out the latest Unreal-powered game out with your friends while your eyes melt to amazing graphics - for that you'll need the latest video card or console. This would be about a homebrew community that doesn't have to hack into hardware and reverse engineer code to get samples running, but one that could leverage Apple's more than willing game developer assets right off the bat. While the initial cost is certainly higher (I don't think I need to comparison shop a new Mac Mini against a used Dreamcast), it would instantly eliminate the black box that "protects" every other console out there.


So what would it take?

Obviously, a Mac Mini
For the dev platform, I think someone would possibly be stuck with the lowest end model Mini. I know that probably bites, because most people will prefer the Mini with at least a little more RAM to it. However, this would help insure that whatever was developed on the Mini would run on almost any other Mini.

Means to a Television
The Mini is already built for it, though for us "regular television" folk, we'll need the adaptor above.

A pair of XBox Controllers ... and the means to use them
Someone's already written drivers to hook up some XBox controllers to your Mini. So just grab some USB love and hook it up.

Some Game Development
So you've got your mini, slapped one side to your 32" and the other to a pair of joysticks. You can't just sit there and stare at nothing, right? Here are some starting points to making your own Apple game:

Apple's Own: Out of the box, OSX doesn't sound like such a shabby framework.

Torque: The rockstar of indie engines, Torque powered Tribes 2 ... and is happy on an OSX box.

PTK: Little company called Phelios has made a starter SDK for Windows and OSX. While you still need some C++ knowledge and a compiler, Phelios is willing to do some of the heavy lifting.

BlitzMax: BlitzBasic has been around for a long time - and this version of the low entry gaming SDK is currently OSX only.



So $500 for a Mac Mini, $20 for S-Video adaptor, $50 for a pair of shiny new XBox controllers and $5 for some software to run them and about $100 for and SDK ... you get your own personal gaming console and development platform for less than $700. Remember, just a dev version of a PSP costs more than a economy car - and try to tell me it isn't a good deal.

Naturally a few technical concerns would remain. Like how easy is it to code for multiple joysticks and other console - orientated designs ... but at least the majority of the hard stuff has been eliminated.