Hyperwares Games

Croak! title screen

Croak! was written in 1992 because a friend wanted a decent Amiga version of Frogger. At that point I hadn’t managed to complete anything worthwhile for the Amiga, a machine which had so many other fun ways of wasting your time. Croak! took about a month to write, then I submitted it to Amiga Format magazine, and it took off from there.

If you are unfamiliar with the game concept then here is the synopsis from the readme file:

This program attempts to simulate, as accurately as possible, one of the most fascinating stages in the life-cycle of the Australian Cane Toad. As everyone knows, the eggs of the Cane Toad are laid within the carcasses of dead sheep. In this nutrient-rich environment the tadpoles quickly mature, and soon there are a multitude of young toads ready to begin their famous migration to the nearest creek or river bed. This journey frequently takes them across busy roads, and rivers whose erratic currents and high toxicity defy the bulky toad’s best attempts at swimming.

Croak! gameplay

Croak! was not an exact conversion of Frogger and never tried to be (one reviewer described it as perversion rather than conversion!) The only Frogger I’d ever played was Hoppy for the TRS-80 Model 1. I didn’t even like Frogger and would have preferred to have released a completely original game. I know, however, that the success of Croak! was entirely due to the fact that there was a demand for Frogger on the Amiga. So I’d like to take this opportunity to kiss Konami’s butt and encourage everyone to buy whichever official Frogger they’re selling at the moment.

Croak! was never placed in the public domain. Amiga Format solicited for coverdisk submissions and paid me a token amount for the right to publish it, but that’s as far as it went. So now I officially declare Croak! to be in the public domain and all you people who copied it can finally sleep at night!

If you have an Amiga emulator (or a real Amiga) you can download CROAK.ZIP which containes a bootable ADF file. Make sure you emulate an early Amiga like the A500, or the game will run too fast (as seen in the YouTube video below).

Croak 2

The sequel, Croak 2, was released in 1995, resplendent with magic butterflies, an NTSC mode for the Yanks, spreadable blood stains, less flicker, no speed issues and generally more polish. This time I included a shareware notice.

Croak 2 title screen

A friend of mine uploaded it to Adam, a local BBS. Two years later it appeared on an Amiga User International coverdisk.  Two very noble individuals have sent me the optional fee. Many thanks to them.

I later discovered it had a bug where the frog was invisible if you launched the game from Workbench on some Amigas (something to do with setpatch?) but it was fine if you booted into it.

If you want to play Croak today, then Croak 2 is the version to get. Download CROAK2.ZIP for the bootable ADF file.

For a bit of fun, I’m going to maintain Croak 2’s status as shareware. Here’s a PayPal button to make it easy for you if you’ve been plagued by guilt all these years.

Read more…

Yacht

This is the penultimate entry in this series of posts. For my final entry I plan to feature the game that made me an international superstar. No really - I actually physically met someone from overseas who knew me from that game. And this was before the Internet took off. But this isn’t that game.

Introducing  Yacht - a Frankenstein’s monster of code that combined BASIC with machine language subroutines and was so difficult that I never even tried getting friends or family to play it.

The sad thing is that this was 1987. That makes me 16 or 17 years old and a first-year university student. It also makes the System-80 totally obsolete! What was I thinking? Well, I was too young for the University Bar…

You pilot your yacht around 9 different courses, adjusting your sail to make best use of the wind. The idea was to angle the sail so that if you imagined the wind bouncing off it, it would bounce behind you. It was actually possible (and frequently necessary) to tack into the wind like a real boat.

If you want to accept the challenge, load the Yacht cassette image into your emulator and follow these instructions:

Read more…

Stompy

“Oh no!” you wail, “not another game he made when he was a kid that no-one played or cared about, and which no-one cares about now either!”

I’ve actually skipped at least ten games, so stop complaining. Stompy (1985) is a lot like the last game I featured, Splatter. The difference is that Splatter was written in Microsoft BASIC and Stompy is 100% Z-80 Assembly Language.

To play it, load the Stompy cassette image in your emulator. Type “SYSTEM”, then type “S”. When the game is loaded, type “/” to run it.

If you’re interested I’d like to tell you how you write a program in Assembler on a 48K Dick Smith System-80 cassette-based system…

Read more…

Splatter

Splatter (1984) is another game I wrote when I was a kid, that no-one ever played.

You are the guy on top of the rows of bricks. The bird-thing is trying to come up to the top. You try to kill the bird by jumping, which dislodges a brick beneath you to hopefully fall on its head. Dislodge too many and you fall through.

As before, if you want to play this you will need a TRS-80 Model 1 emulator and the Splatter cassette image. The game is written in BASIC, you type CLOAD to load it and RUN to run it.

Keep reading if you would like to see what the vintage BASIC source code looks like. I actually went to some effort to de-tokenize it from the cassette image, just for you.

Read more…

Protector

This is the first entry in a series that will showcase games I wrote when I was a kid that no-one ever cared about or played. No-one. Nobody cared what I did alone in my room for hours on end. Maybe they thought I was doing something else. Anyway, I’m not bitter.

This game is called Protector. The guy with the gun is you. The guys with the clubs are harp seal hunters. The things on the right are harp seals. One of them has been clubbed and skinned already…

According to the title screen, this game was made back in January 1984, which would have made me a very disturbed 13 year old environmentalist. To this day I still can’t explain why everyone appears to be wearing clown shoes.

If for some bizarre reason you want to play this, you will need a TRS-80 Model 1 emulator and the Protector cassette image. The game is written in BASIC, you type CLOAD to load it and RUN to run it. That’s as much help as I’m going to give you. I suspect that if you’re into this sort of thing, you’ll really enjoy working out the rest! You’ll certainly enjoy it a lot more than actually playing the game.

Battery life is the one major thing I hope improves with the next generation of iPhones and iPod Touches. My wife and I use our Touches almost exclusively for gaming, and nothing sucks juice like my wife playing games. She will typically drain a full battery in one gaming session - we’re talking about less than two hours here.

Don’t tell her, but I’ve just bought her a USB charger for Mother’s Day (no, I’m not married to my mother, but my wife is a mother and she thinks that entitles her to presents from everybody). She can hopefully then just sit in bed plugged in to the mains and stop bugging me to recharge the thing.

So this brings us to the topic of the day. What are the things that we developers can do to reduce battery usage and the carbon footprint of our games? I have three suggestions, and they are all related to frame rate.

1) Use the minimum frame rate that looks good

The iPhone and Touch can update their screens at a maximum of 60 frames a second. So there’s no point going faster than that - give your app little microsleeps. With people, microsleeps can make you feel more refreshed. Conversely, the idea with games is that they will make your screen less refreshed. (Did I just make that lame joke? Slap me!)

Don’t stop there, though. Try running your app at 30 frames a second. If it still looks smooth enough, then cap it there. Your app is now napping for about half the time. Obviously this won’t make the battery last twice as long, but since your game is using the CPU and graphics half as much, this will make a big difference.

2) Don’t draw frames if nothing changed

Suppose we are running our game at 30 FPS. The logic will be updating at this rate, but if nothing is moving or animating then there’s no point compositing the scene again. Give the graphics chip a rest.

3) Use Variable Framerate Technology for Games

The first two suggestions were pretty obvious, but I’m really excited about this one, although its probably only suited to 2D games. Variable Framerate Technology for Games, or VFRG is a cool (IMHO) idea I just came up with.

The basic idea is to dynamically adjust your framerate based on how fast your objects are moving or animating. Some video compression schemes do a similar thing.

Here’s an example:

• Firstly, work out how smooth you absolutely need your motion to be. Let’s say we are happy to move our objects in 4-pixel jumps.
• At the top of your game loop, store the current time (accurate to at least milliseconds)
• After you’ve done all your game logic, find the fastest moving object on screen. Suppose this object is travelling at a speed of 100 pixels per second. Divide this by 4 to get a target rate of 25 FPS.
• Then find the fastest animating object on screen (assuming a flip-book style of animation). For this example, let’s assume that this object is animating at a speed less than 25FPS, so we won’t consider it. But if it was animating faster, we would increase the target rate accordingly.
• Divide 1000 by the target rate, to get an update interval of 40 milliseconds in this case.
• Draw your scene.
• Using the time you stored earlier and the current time, work out how many milliseconds have passed. Subtract this from 40, and go to sleep for the result (assuming the result is non-negative!).
• Rinse and repeat.

I’ve got this working with my game at the moment, in conjunction with an upper framerate cap of 30FPS. I have a little overlay display that shows me the number of frames drawn each second, and can see this drop from 30 down to as low as 10 depending on how fast things are moving.

The only area where this all comes unstuck is in responding to user input. For reasons of responsiveness, chances are you don’t want to detect changes in finger position at a rate of 10 times a second or less. You can compensate for this by putting a lower threshold on frame rate (e.g. 15FPS) and perhaps override VFRG and run at your upper rate limit whenever a finger is in contact with the screen.

Now I’m just going to fire up Photoshop and design a funky little green logo for VFRG to stick on my loading screen! I’m only half joking - if you’re smart you can use low battery consumption as a major selling point for your game.

It’s been eight weeks since I received my Mac Mini, which is an eternity in iPhone development time - so how far have I progressed since then?

I’ve been developing C++/MFC applications for Windows full-time for 11 years. Two months ago I knew nothing about OSX, Xcode, Objective C, Cocoa Touch and OpenGL ES - all of which I needed to master and which presented a considerable learning curve. I just had to trust that my career had given me the skills and experience to adapt to these technologies. I had also written a successful public domain game for the Amiga way back in 1992. This gave me enough confidence in my abilities to splurge the money on the hardware and start on this journey.

OSX wasn’t hard to adapt to, once Apple’s awful mouse driver was replaced. The inability to easily maximize windows to the entire screen is the worst thing for me. I always work full-screen on Windows and don’t see any benefit to having bits of  junk visible around the edges of the window I’m working in. It’s just distracting and a waste of space. If I need to see two windows at once, I put them on different monitors. Unfortunately I don’t have that luxury on the Mac Mini at the moment.

Xcode seems a bit temperamental and I haven’t fully mastered it yet. But I’m going to go out on a limb and say that Microsoft easily rules the roost when it comes to development tools.

Learning Objective C was kind of like those Magic Eye pictures. I’ve been writing C++ code for fifteen years, but Objective C looked bizarre with its square brackets everywhere. Then after a short while, and crossing my eyes at the screen, suddenly something flipped and it all made sense.

So far all my Cocoa code has been ripped out of demos. You don’t really need much if you’re writing a game.

As for OpenGL ES, I stole enough code from the internet to make a 2D layer on top of it, and now I don’t need to think about it ever again!

I am currently at the point where I have a nice 2D engine which is throwing lots of objects around the screen, colliding and rebounding nicely off walls and each other. The direction of the objects can be altered by swiping with a finger. I also have some nice art assets developed. This is the foundation for a lot of possible games but I don’t want to show my hand just yet.

As far as I can see, the major technical challenges are now out of the way and I can just get on with writing the actual game. Soon it will be time to take some long-service leave from my full-time job and attack this project with all my energy.

As a long-time Windows developer new to the Mac, it took all of five seconds before I realized something felt horribly wrong with the mouse on OSX. The pointer would consistently stop short of the spot I was aiming for. As my hand slowed down, the pointer slowed down even faster, making those final few pixels a chore to traverse.

Apparently Apple changed this between OS9 and OSX and there is no official way to configure it more to your liking. I find it really quite amazing that they could screw up the fundamental core of the whole Macintosh user experience and leave it completely busted for numerous revisions since.

Oh dear, this isn’t really setting the right tone. Apple-bashing on an iPhone developer’s blog, in only the second post? I can almost feel the mighty fist of Steve Jobs hovering over me, ready to smite my provisioning profile into tiny pieces and banish me back to the bowels of Windows from whence I came.

To be fair, I’m sure there are lots of people who are happy with the mouse acceleration in OSX. But they’re probably all using trackpads.

For those people who are less than happy, rejoice for help is at hand. And it comes from the most benign and benevolent of sources - Microsoft!

Just download the IntelliPoint driver and make your Mac usable. You don’t need to be using a Microsoft mouse. Thankyou thankyou thankyou Bill!

(See this article at TidBITS for a more detailed analysis and some less optimal solutions)

I love it! I can now call myself an iPhone developer and all I had to do was give Apple a hundred bucks. I think I’ll go out and get myself a bunch of business cards printed right now!

Over the coming months I plan to keep this blog updated with the progress I’m making with my first iPhone game. My hope for this game is that it has to earn me at least enough to cover my new Mac Mini, iPod Touch and developer fee.

Of course the dream is for much more. Hyperwares Pty Ltd needs a new way of making money. The iPhone will be its saviour and make me stupidly rich!

Nobody dare tell me otherwise!