Posts

Posted on

Bork3D Game Engine for iPhone

I’ve decided to put the foundation I wrote for Anytime Golf up for sale. I’m calling it the Bork3D Game Engine. I think I can carve out a niche in the iPhone engine space for programmer-types with high expectations of the hardware that want a solid foundation on which to build their game. There are other options out there but I believe most game developers look at those and fear (rightfully so, I hear) that those other options won’t meet their performance criteria.

Selling a game engine is an interesting thing.  I think the Unity folks have a good business model: they’re clearly targeting non-programmer types who want to put together something 3D quickly.  Torque has their iTGB offering that’s similar.  There’s a good deal of money to be made there.  Unfortunately it doesn’t produce great games. (Oh no he didn’t!) OK in fairness these engines produce awesome games on PC. They are awesome PC engines. I’m a licensed Torque user and I love it. They’re just not mobile engines.

The Bork3D Game Engine was built for mobile platforms. It actually has it’s roots in Rude Engine that I wrote for Vector Blaster, and can run on Pocket PC, Symbian and N-Gage in addition to iPhone. But it isn’t a complete game engine by any stretch of the imagination. If you want in-game content creation tools and a scripting language please leave. However if you want to build in-game content creation tools and install your favorite scripting language, c’mon in!

So what do you get?

  • All the source code
  • OpenGL ES abstraction layer
  • Debug-rendering API
  • Component-oriented game object system
  • High-performance static and boned mesh rendering system w/ tool pipeline for 3dsmax and Maya
  • Decorator system for rendering billboards
  • Texture manager w/ tool pipeline
  • Runtime “tweaker” for changing game variables via a web browser
  • User interface widgets w/ abstractions for handling iPhone user input
  • Font renderer w/ tool pipeline for generating fonts (supports unicode)
  • In-game profiler
  • Audio system for sound effects and background music
  • Integration with the Bullet Physics SDK
  • Unit test framework

And what does it cost? I’m selling it for only $49 (if you’re indy). Fourty-nine bucks. That’s a lot of code for not much. I’m probably crazy. I guess I’m softening as I grow older, considering this is 1/15th what I was selling Rude Engine for a few years ago.

See bork3d.com for more information.

There are also threads on TouchArcade and iphonedevsdk.com about the engine.

Posted on

Anytime Golf now $0.99

My game Anytime Golf is now only $0.99!

Although getting the word out about the game has been challenging (a lot more challenging than last year with my first iPhone game), folks who have found the game seem to have great things to say about it. Here’s a selection:

“A quality game of golf… cracking 3D graphics and realistic physics… hard not to recommend.” AppGamer.net

“I am struck by the amazing 3D graphics that you see in this app, but this is more than just a beautiful game… The interface is easy to navigate and the game play is a load of fun… If you love golf you would be missing out big-time if you didn’t give Anytime Golf a try.” iPhoneAppsFinder.com

“Great 3D graphics and excellent game play make this a very addictive app.” iPhoneNess.com

“The holes are really well designed… The physics are superb… The graphics are among the best on the iPhone. A+” App Store reviewer

You can purchase Anytime Golf on the App Store here.

Posted on

PSP Go hands-on

I got to play with the new PSP Go today at E3, here’s my thoughts.

It’s small, and it’s thin. Like, cramp your hands thin. It’s obviously designed with little kids in mind. I think the space between the face and the back is less than a half inch. On top of that, all of the face buttons are drawn in closer to each other.. I only got to play it for about 10 minutes but the whole time I had ergonomic concerns.. I don’t think I would last more than 30-45 minutes on it tops.

The screen is smaller. The large screen I thought was the original PSP’s best feature. It was comfortable to play games and watch video on the PSP. Why change that?

It looks great and has a solid feel to it. Sony build quality you would expect. Well, not entirely. The face buttons feel a bit more fragile, but I thought the original PSP’s buttons felt fragile until I got used to them.

But $249? For reals? The device is cheaper to manufacture than the old PSP (I assume, since it lacks a UMD drive and has a smaller screen), and you’re charging more for it? In this economy? With very little new content coming on PSP in 2009? OK.. whatever.. I’m just asking.

And yes, still no second-analog stick. Why? I have no idea. But seriously. Why? There’s room for it on the front panel. Gamers want the second-analog. Developers want the second-analog. Everyone wants the second analog. Give the people what they want.

Posted on

AMD launches website celebrating anti-trust victory over Intel

I’m not sure exactly why, but I find this disturbing.

Never-mind poor sportsmanship. You just threw out all opportunity for an out-of-court settlement should the appeal not go in your favor.

At the end of the day, do you think consumers really care? Processors aren’t like shoes or lead-based toys. I don’t care how they get in my computer, I just want them to be fast an reliable. You’ll get exactly three anti-Intel geeks to rally to your cause and the rest of us will just scratch our heads… huh?

Posted on

Subversion woes

In the version control world, I’m a big fan of perforce. I first became a fan when I saw how fast it was–it can perform checkouts of gigabyte-sized repositories extremely fast. I also really liked the perforce workflow–changelists are the “normal” way of working. However I started to love perforce when I began playing with it’s branching capabilities. It’s ridiculously easy to create and integrate branches, and they have wonderful tools for helping you understand branches.

At my new workplace we’re on svn, and while I wouldn’t say I “hate” it… That’s a pretty strong word… I am “very displeased.”

Speed isn’t so much of an issue here because we’re only dealing with megabyte-sized repositories, so a minute or two to checkout ~100mb or so isn’t too painful. The svn workflow has taken some getting used too. Nobody works with svn changelists–there are no good tools for managing changelists so it’s wasted effort. It’s easier to just do another checkout of the repository and work in there. Since our repository here is relatively small this is no big deal. (I couldn’t imagine what it would be like with a larger repository! Yikes.)

Branching in svn is downright painful. I suppose if you had nothing but text files running on one operating system and everything was in one flat directory structure you might say, “What are you talking about? It’s so easy!” but so far that hasn’t been my experience. Here are the problems I’ve encountered:

  • Merging subdirectories instead of merging from the root. Apparently this is a known “no-no” according to the Subversion book. I made the “mistake” of merging a subdirectory a few revisions back and now whenever I merge from the root it wants to re-merge all the files in those subdirectories every single time. It marks their properties as modified even though they’re not being changed. Maybe this is just svnmerge.py being diligent but it’s annoying to see this massive list of files every time I merge, when really the “meat” of the merge is in just a handful of separate files. Weak sauce.
  • Merging eol-style properties. There’s a known bug in svn 1.5.0-1.5.4 where if you make eol-style changes to a branch and you try and merge that to another branch you may get a “inconsistent newlines in /tmp/tmp” error. I encountered this and the only way I could figure out how to get around it was to upgrade to svn 1.5.6, make the eol-style changes in the branch, commit, then perform the merge. I then had to downgrade back to svn 1.5.1 because 1.5.6 couldn’t deal with the branched subdirectories I mentioned previous. I’d see an “Error reading spooled REPORT request response” message when it got to those subdirectories that had been previously merged.
  • Merging inconsistent newlines. Really? This problem arrises because svn stores on the server whatever newlines you give it. I can’t think of any reason why the svn server would not store files as ‘eol-style=native’ on the server by default. It seems like storing the client’s newline format on the server is an exceptional case, not the common case. It’s irritating to have to merge newline inconsistencies.

I miss perforce. Somebody needs to develop “poorforce”, a cheap version of perforce. 🙂

Posted on

Anytime Golf: Magic Touch now available on the App Store

My game Anytime Golf: Magic Touch just went up for sale on the App Store.

Marketing speak:

Great golf anytime, anywhere!

Stunning graphics: Enjoy highly detailed modeling displayed in smooth interactive 3D. You will agree–this is one of the best looking games on iPhone!

Intuitive interface: Slide your finger down across the touch surface to perform your backswing, then flick up for the downswing. Your skill and grace controls the power and accuracy of your shot!

Tournament mode: Unlock new challenges by competing in 9 and 18 hole competitions. There are 6 challenges total!

Practice mode: Not up for a full 9 or 18? Hit the driving range and hone your game!

Anytime Golf: The most realistic golf experience for iPhone!

Click here to purchase!

Anytime Golf: Magic Touch’s Facebook Page
Anytime Golf: Magic Touch's Facebook Page

Posted on

Anytime Golf: Magic Touch nearing completion

My game Anytime Golf: Magic Touch (to be released under the label Bork3d Games) is almost ready for the App Store. I’ve been working on this project for quite a while with a very talented games-industry friend, Jake Helms. When we started we set out to create the best looking, most intuitive and most fun golf title for iPhone, and I think we hit those marks. We’ve spent a lot of time squeezing framerate out of the device and pushing polys to their limits (in some scenes we’re well into the thousands). Our touch-based swing mechanic has gone through numerous iterations in an effort to create something with depth and sophistication but that you can still pick up in 2 seconds.

And we think it’s pretty damn fun. It has that “barely out of reach” quality we were looking for, where, like bowling and other (real life) sports games, just when you think you’ve mastered it you slip a tad and mis-execute. I find when I play it I start to become over-confident after a while and the game bitch-slaps me back in place. The moment I knew we found “it” was when I was on the 9th hole, one under par, and my finger was trembling because I was so nervous about screwing up the final putt.

Working on the game has been fun too in it’s own way. Every experiment we’ve ran or tweak to a mechanic has uncovered more and more ideas to try. But sadly there comes a time when you just have to call it “done”. There’s a lot more we could do on this game (we have a huge list we’ve been tracking) but we’re saving it for version 2. There’s only so much two guys can do. 🙂

iPhone Games Network has posted a video on their website of the first hole. Look for the final game soon on the App Store!

Posted on

Computers Take Flight

Much has been written and re-enacted of the trials NASA experienced putting people in space–but the focus is usually on the astronauts, the faces we put on space travel. Some attention has been paid to the propulsion pioneers and the rocket engineers that made it possible, but rarely do you hear about the software jocks that wrote the code to run the rockets.

I had searched for a while for a text that gave the software perspective on the space missions and had given up. Today I came across just such a text almost by accident: Computers Take Flight: A History of NASA’s Pioneering Digital Fly-By-Wire Project. I haven’t read it all yet but after reading chapter 3, “The Reliability Challenge and Software Development,” I’m hooked:

“Software quickly became the main driver of cost and schedule. The techniques of making reliable hardware were know to engineers before the program began. However, ensuring software reliability was still an immature process.“

Not much has changed in 40+ years.