Version 1 of my 40 level rapid-fire platformer ‘Not Just a HatRack’ is ready for the Arduboy community. Guide Karlville through all 40 levels in the fastest time.
This is my first Arduboy game and has been an excellent learning experience; I hope you all enjoy it, and don’t forget to tweet your final times at me - curious to see how quickly people make it through (Hoping to start up a ‘Hattery of Fame’ on my website)
Files are available for download from my website:
Congratulations! This is an interesting and fun game. I think it adds some unique variations on previous similar games.
After reading your blog entry about it, I’d like to point out that 60 frames per second is not the maximum you can use for setFrameRate() / nextFrame(). Since the frame rate you specify is translated into integer milliseconds (1000 / framerate), the maximum theoretical rate is 1000. In practice, it will be quite a bit lower, being limited by the time it takes to do whatever calculations and rendering are required for a frame, plus the time to write the screen buffer to the display itself if you use display() for each frame.
For you, and any other developers reading this, there are a couple of tools provided by the Arduboy2 library that you can use to determine if you’re rendering fast enough to keep up with your chosen frame rate.
The first is function cpuLoad(). Calling this will return the percentage of time that you spent doing work in the last frame (i.e. the time not idling waiting for nextFrame() to return true). If the value returned is less than 100, then your code is not exceeding the time allowed and you can use the value to get a rough idea of how much extra time is available. If it’s greater than 100, then your code is taking more than one frame period and you’ll actually be running slower than desired.
During development, you can call cpuLoad() and report the returned value in some way, such as by putting it somewhere on the screen after rendering the game content.
Keep in mind though, that the act of calling cpuLoad() and reporting its value will take a bit of additional time itself, which will be included in the reported value, so the actual percentage will be a bit lower in the final game without the additional cpuLoad() calls and reports.
If you just want to know if your rendering time is exceeding the chosen frame rate, you can use nextFrameDEV(). This works exactly the same as nextFrame() but additionally will light the yellow TX LED at the bottom left of the Arduboy whenever the allotted frame time is exceeded. You use this function by replacing all calls to nextFrame() with nextFrameDEV(). Then, if you see the TX LED come on any time while playing your game, you know your rendering has taken too long.
You should remember to change all your nextFrameDEV() calls back to nextFrame() before releasing the game, as nextFrameDEV() takes up a small amount of extra program space and CPU time.
Also note that if your game uses the USB port to communicate with another device for some purpose, the TX LED will flash during communication, which does not indicate excessive CPU load.
Thanks! That’s interesting and useful. The whole process of putting a game together (even one as simple as this) has been a steep learning curve, but the community have been super helpful on several occasions 
. I will update the blog post with this info… As you say, it is a useful thing to know.
The first entry into the Hattery of fame has been posted - a respectable 387s, 97 deaths
Amazing game, really reminds me super meat boy. I just miss some lovely hat-splashes sounds 
Thanks! … Toying with the idea of adding sounds to the next version (which I will hopefully get around to at some point)
This is my favorite of your games so far 
, I love the physics of this zooming top hat and feel compelled to place it upon its rack. 10/10 would place on rack again. Any plans on adding a save feature to a future build?
Thanks! It was my first venture into the world of Arduboy and came out pretty well. I don’t really have plans to add a save. At the time I wanted to keep it quite focused (and manageable as a first project so that I didn’t get bored of development), but also I like the idea of forcing the single playthrough in one go for a final overall time. I passed an early version around between some friends a while ago and we had good fun shaving seconds off each other’s time for completion.
Not even a scoreboard?
Might be worth saving the best times to EEPROM so players can keep a record of their best times.
By the way, what licence is the source code released under?
Is it just a ‘look but don’t touch’ deal?
Hmmmm… Tbh I’d never considered the idea that people would keep playing it for long enough to want to record their scores… But I’ll keep it in mind when I get around to playing with some EEPROM stuff.
I did consider using an open source license, but also I know that team ARG were stung by it a little while ago. I’d like to retain creative control over the ‘game’ more than anything, I wouldn’t like the idea that someone could take it and… Say add a pause button… That’s something I made a decision to leave out. Having said that, I’ve no problem with the code being examined and if people want to write their own that is “heavily inspired” by what I’ve done (or how I’ve done something) then of course that’s all cool.
I think I’d feel pretty differently if I’d made a ‘tool’ to do something. There I can see the value of using open source.
EEPROM’s not as scary as it sounds, if you’re comfortable with calling functions and different datatypes then it’s something you can learn to use in less than a day, between a few minutes and a few hours depending on how fast you take stuff in.
Aside from the syntax being different and a small caveat about which function you use for writing, it’s not that different in concept to reading and writing from an array.
Was that the thing where their games were being used with the GameByte?
If so I’m not sure whether that would be the licence’s fault, it could be possible to load their games onto a non-Arduboy even if you only had a binary copy of their games.
I’m half and half on that. On the one hand I understand having a vision of what a game should be, but on the other hand I like modding.
There’s other reasons for and against depending on how much say you think players ought to have about the development of the games they play and whether or not you think a game being successful is more or less important than the developer being happy with it, but that would be getting into a philosophical debate.
I think it’s definitely something worth revisiting.
You mentioning that you “passed an early version around between some friends” made me imagine a group of people taking it in turns to best each other by passing the same Arduboy around, if you’d had an EEPROM scoreboard that would have made that kind of playstyle much easier.
I’ve also heard of other people on the forums doing similar things with other games, especially those with siblings or children.
This game is so good. It’s just like a portable meat boy but you can’t put it down or back to lvl 1… I don’t really want to put it down 
Thanks!! Yeah, it was a conscious decision to be a single run thing. Part of me would like to go back and tweak it, but I also sort of think that maybe I should just make a new game for Karlville… 
Love the game! But, is level 40 even possible? I can’t get past the very first spikes…
Nvm, figured it out! 3003.40s and 706 deaths later 
Thanks for the great game!
This game is awesome. My only tiny nitpick is I wish the death animation was a bit quicker.
Really enjoying it, I like how you introduce new mechanics gradually, like the slick walls.
edit: man, level 24 is brutal O_o
glad you got there! Thanks for playing 
️