But wait, there’s more…

July 6th, 2009

Following a four-month sulk about our idea having been implemented already, the apes are back with another mind-blowing game project. Break-tris will have the effects Breakout and Tetris had on the game industry, but will have them at the same time!

The internet is full

March 9th, 2009

Following the recent excitement about the latest apeworks brainchild, it’s turned out that the 2D game we were writing has already been written. Pretty much every detail of this game, down to the name itself (!), matches what we were aiming for. Freaky, eh? A reasonable thinker can conclude that, not only is the internet full, but that every innovation mankind is capable of has been achieved (based on a sample population of this one event). We need to do some serious thinking about what direction this project takes next. See what we were trying to do here.

Up t’summat!

February 19th, 2009

We at apeworks are up to something. Our latest brainchild is an exploration into the world of 2D games. While the industry has been rocked by photorealistic titles like Gears of War 2, Resistance 2 and Danger Balls, there have been fascinating developments in casual games, and we’re not above cashing in. Rock on over to sourceforge.net and see what we’re at.

How not to write a computer game

December 30th, 2008

Devout apefans will find this hard to believe, but Danger Balls is not perfect. No, no, it’s true. In fact, I think I may have the dubious accolade of having made every mistake possible in the creation of a game. For the benefit of other aspiring developers and hobbyists, I will now list these transgressions, in no particular order.

How not to write a computer game

  1. Write everything from scratch. Granted, it can be fun, insightful and downright educational, but writing your graphics engine from scratch is the slowest way to make a game. Nearly everything you want has probably already been written; don’t be afraid to stand on the shoulders of giants.
  2. Build the engine first, add content later. This sounds obvious now that I say it to myself, but a game has to have a point, however abstract or whimsical, and it has to have it before you write a line of code. I spent years developing Danger Balls as “some kind of tank game” before ever adding any balls.
  3. Close your source. Not having written any open-source software, I can’t yet sing its praises, but I can tell you that the knowledge that no one will see your code allows you to do dirty, shameful things to it. Open it up for the world to see and, even if no one’s interested, you’ll be forced to take a certain pride in it.
  4. Take seven years. Enough said.
  5. Don’t update your website. The warning sign here was when the owner of another website with a similar name remarked that he wasn’t able to tell what it was we were doing. One major overhaul of the site later, I hope it’s a little clearer. If not: we make computer games.
  6. When you do update your website, hand-write the HTML. Even after the overhaul, it took me a few months to realise that what I was doing on the site was blogging. Once I had installed Wordpress, this became a lot less of a chore. Use the right tool for each job.
  7. Hand-write XML. I recently decided that I was too old to be hand-writing XML. It you have to write XML, treat yourself to an editor.
  8. “Those are just proof-of-concept models; they won’t be in the game”. I actually believed this when I said it, but it’s all too easy to leave test data in the game. Beware the dreaded “good enough”. Either bin your test content, or develop your engine against release-quality content.
  9. Keep it to yourself. Until I announced a release date for Danger Balls, the only indication of any progress was a “coming soon” notice on the public site. Behind the scenes, some decent work was being done, but all on the private wiki and issue tracker, with nothing being blogged for the benefit of the public.
  10. Don’t have a deadline. The only reason Danger Balls is available now is thanks to a drunken promise I made last year to finish it within three months.


September 30th, 2008

Danger Balls will soon be getting an audio-visual make-over thanks to contributions from some highly talented artistes. Alien Items will be sassing up the soundtrack with some atmospheric compositions, while O.K. Erok will be crafting some designer tanks for us. Yum yum!

Linux build released

September 25th, 2008

Good news for nerds, cheapskates and stubborn people, as Danger Balls is now available for Linux! Continue to fight The Man by downloading your royalty-free, take-that-Bill copy here.


September 18th, 2008

Not that you’d know, but this site now uses some very fancy blogging and feed parsing to provide your news updates. For the nerd that dwells within you that wants to exactly how: Wordpress provides an RSS feed and SimplePie parses the feed into HTML. Nerdtastic.

This will make adding news ridiculously easy, assuming this isn’t the last new thing that ever happens.


September 4th, 2008

In the good old days, all XML for models in the Primate was hand-written. I took an evolutionary step recently by downloading an actual XML editor, rather than doing it all in Notepad.

Now, I’ve finally managed to build part of a model in Blender (that’s an actual model editor, people!) and export it to Primate XML.


I just had to run it through a couple of teensy weensy SED statements:

# Points
s/\([-0-9.]\+\) \([-0-9.]\+\) \([-0-9.]\+\),/<point x=”\1″ y=”\2″ z=”\3″\/>/

# Indexes
s/\([-0-9]\+\), \([-0-9]\+\), \([-0-9]\+\).*/<index>\1<\/index><index>\2<\/index><index>\3<\/index>/

Simple, eh? You’d do that in your sleep! It took me less than 2 hours to convert an object!

It doesn’t work properly, of course. Still, great days.

OpenGL transparency

September 3rd, 2008

You can’t have danger balls without explosions, and you can’t have explosions without transparency. I decided I’d have two types: transparency in textures - for billboarding pictures of dirt being thrown up in the air - and overall transparency of objects - for clouds of semi-transparent smoke.

A simple matter of enabling GL_BLEND, setting a blend function adding an alpha channel to texture images and setting alpha values on object colours…

But what’s this? OpenGL documentation saying there’s more to it…

“When using depth buffering in an application, you need to be careful about the order in which you render primitives. Fully opaque primitives need to be rendered first, followed by partially opaque primitives in back-to-front order. If you don’t render primitives in this order, the primitives, which would otherwise be visible through a partially opaque primitive, might lose the depth test entirely.”

You guys crack me up! How could something so basic necessitate such a contrived algorithm? This must just refer to mid-80s SGI hardware or something…

WAAAAAAAGH!! It’s true! If you don’t draw primitives in the right order it nobbles the whole thing! Come back, Java3D, all is forgiven! I promise I’ll use you in Primate 2.0!

Okay, okay, calm down. I can still use if for explosions, because they get added to the end of the draw list and only last a couple of seconds, so there shouldn’t be any transparencies overlapping. And what kind of a tank game would it be if there was more than one explosion at a time? Ha! I’d like to see that!!

Danger Balls 0.9.3 released

August 12th, 2008

Unperturbed by a hilariously low number of downloads of the previous release, apeworks is proud to Danger Balls V0.9.3, available now to download, featuring another brand new Defender level, the dreaded Pit. Can you defend the base against the onslaught of the fearsome danger balls?? Ooooooh…