Joustish - A game quite like Joust



Joustish is a game that is very similar to the arcade classic Joust, but with some minor differences.

Flap around on your bird like a madman as you attempt to unseat the enemy bird riders! Hit an enemy when you are higher than them and they will be separated from their bird as a harmless egg. Don’t leave those eggs lying around, though, or a new enemy will eventually spring from it!


Featuring endless but ever-changing waves, as the terrain will alter every 10 waves until the lava below is exposed.

I developed this in the ProjectABE emulator, so please let me know if it works well on the real hardware.

Here is the source repository, and here are the latest releases, which have links to each release version’s precompiled .hex file.

The game is mostly complete, but I couldn’t test saving highscores to EEPROM because it appears that ProjectABE either doesn’t save the EEPROM state for .hex files dragged into it, or I’m still doing something wrong. Also, I’m hoping to add sound in the future, but sound support in the emulator isn’t ideal. Still, it’s been amazingly helpful to be able to use ProjectABE.

Also, I recorded animated gifs in both the online and older offline versions of ProjectABE, and it seems like the speed of the gif is slower (or a lower framerate?) than normal in the online version, but faster than normal in the offline version.

Online emulator:
Offline emulator:

This is a submission for the Arduel contest.

(Simon) #2

Great effort on developing this only using ProhectABE … the problem with the emulator is that a program that runs perfectly o it may run a lot slower on physical hardware if your logic and rendering exceed the FPS.

I will give it a run when I get home. It looks great !!

(Pharap) #3

Is it true, is the contest finally over after nearly 14 months?

(Felipe Manga) #4

Great! I was looking forward to playing this! :smiley:
It’s much Joustier than the Joustish name implies.

I see you’re using a framerate of 15. The gif recorder doesn’t do a good job at speeds other than 60 right now, as it still depends on some hard-coded values. It’s kind of tricky, since gif framerates are not accurate enough: frame times are specified in 100ths of a second, instead of milliseconds.

(Scott) #5

From the source code:

  // Framerate at 15 fps, which hopefully is smooth enough, because
  // the game speed is tied to framerate, so changing it would alter
  // the gameplay significantly

As I recommend for all development of sketches that use nextFrame():
Replace nextFrame() with nextFrameDEV() during development. This will cause the yellow TX LED to light whenever rendering a frame takes longer than the time per frame available, as specified by setFrameRate() (or setFrameDuration()). Whenever the LED comes on, the sketch is running slower than intended.

(Remember to change it back to nextFrame() before releasing the sketch.)

(Felipe Manga) #6

I think it was set to 15 because of animation and framerate-dependent movement, not because of processing.

(Felipe Manga) #7

Do you still see this in the online version? Speed got more accurate in the last update.

(Simon) #8

I have played this on a ‘real’ Arduboy and I can say it is a little sluggish - especially when you are jumping. For some reason, running on the ground seems at the correct speed.

I think the problem is @wuuff doesn’t yet have a physical Arduboy (or he is not prepared to take Arduventure off yet :slight_smile: ). Does this trick work in ProjectABE - probably not, see below.

The emulator will often render at the ‘expected’ speed but when you are playing it on a physical Arduboy it might run slower. My guess is that this is due to the fact that the emulator is much faster at certain functions and it is waiting at the end of each frame for nextFrame(). The real Arduboy is struggling to complete its logic / rendering and is therefore running slower.

I have no data to support this, its just been my observation.

(Scott) #9

Yes, but I thought I’d point it out just it case. If the game play is dependent on frame rate, then it’s always good to be sure it’s actually running at what you think it should be.

(Felipe Manga) #10

If you can find a hex file that exhibits this behaviour, please send it my way. The only situation I can think of in which this might happen is games that use Timer4, since that wasn’t implemented at all yet. The interrupts would slow down a real arduboy by running code that the emulator wouldn’t.
If there are others, I’d really like to fix them.

(Scott) #11

Well, switching to nextFrameDEV() is something you, or other testers, can do, if compiled from source, and then report back to @wuuff with the results.

(Simon) #12

Tried it out and no, its not flash the TX led on nextFrame() … so its purely a coding and game play thing.

(Stephane C) #13

Really a great port/clone of JOUST. plays almost better then the version on my mini arcade at home.
Only thing that is sad is that it’s hard to distinguish our character since they all are the same. maybe our player should be an outline sprite instead? Just a thought.

I agree that ProjectABE is a great help when developing, it saves me a lot of uploading, i can just test things faster using it.

(Pharap) #14

Or maybe just draw a circle/square around the player.

(Stephane C) #15

Yes, a circle around the player sounds like the simple way to do it.

And if you think you could do the outline route i quickly made you the sprites using the atari2600 version as a base. I also noticed that on the atari version the enemies are not walking, so they only use the 2 frames animation for flying.


These sprites may be too big tho…


Thanks to everybody for the feedback! I don’t have an Arduboy yet, so it’s good to hear it plays well.

Hmm, I’ll have to eventually try this on the real hardware to see how it feels. For flapping, I tried to imitate the feel of Joust, where you have to flap rapidly to overcome gravity. I’m curious how it is on an actual Arduboy.

Thanks, but you’re right, those sprites are bigger than the ones I’m using. I made 8x8 bird sprites so I could fit the entire playfield that Joust had on screen, and I was really struggling to differentiate the birds with sprites that small. It may be almost impossible to see on the small screen, but the player’s sprite has a black dot in the center, the player’s bird and rider heads are slightly different from the enemies, and the legs and wings are slightly different. Unfortunately, at high speeds and with such tiny sprites I was afraid the differences would blur together to the player.
Here’s a zoomed-in comparison between a few player sprites and enemy sprites. I tried to differentiate them as much as possible while still keeping them both looking like birds and riders, but there weren’t many pixels to work with.


I have a small update! I received my Arduboy, and after finishing Arduventure, I decided to try some other games and to make sure this worked like I expected.

I tested the game and fixed a small bug with how highscores were saved to EEPROM. Highscores will now save correctly! I also added the option to flap with B. The updated version is linked in the first post.