Kooky Kookies - Neo Retro Game

(Michael) #1

Here is our entry into Game Jam 2.0

Santa has delivered the presents and filled the stockings. Help Santa eat the cookies before the kids wake up and discover him in this match 2 puzzle game. Build bigger sets to get extra time and lots of points.

Game is available for download at neoretro.games


  • Added EEPROM access panel
  • Changed score variable from int16 to int32 since it is possible to get a score higher than 65535

[POLL] Game Jam 2 Vote!
(Erwin) #2

Nice entry! But I think you need to change the way the new cookies are selected, because currently you can get an unplayable board.

Also, no sound yet right?

(Michael) #3

How were you able to get an unplayable board?
You should not be able to select a cookie as they are falling, i thought.

There is sound in the game. Is it not working for you?
Carol of the bells plays on the title screen and there are sfx during game play.

(Erwin) #4

No sound at all.

Yes I agree, but you add cookies at random, so you eventually get an unplayable board:

(Michael) #5

Odd, Sound is in the game. Can you try another Arduboy?

Oh, Yes an unplayable state is possible during new cookie creation. I Hit it about 5% of the time

I can look into the cookie generator…

My current Hi Score is 14559

(Erwin) #6

Yeah, tried on four :stuck_out_tongue:

(Michael) #7

Any ideas how i can have music and sfx on my Arduboys but not on yours?

(Erwin) #8

Not really, can anyone else try the hex file?

– edit: not necessary anymore.

(Michael) #9

The only possibility i can think of is that sound is off on your Arduboys and the toggle in code is not working. I’ll check the code.


(Erwin) #10

By occam’s razor I think a simpler solution is that you uploaded a different file than the one you are using (that is simpler than having 4 improperly configured arduboys)

(Michael) #11

You are correct, I had an earlier version on my site.
Try again, please.
…can’t believe I uploaded an older version

(Scott) #12

Sorry, I won’t upload anything unless the source code is available for examination.

(Pharap) #13

filmote should be asleep since it’s the middle of the night in Australia. (By my calculations he’s in UTC+11:00 so it’s about 02:30 on December 12th.)

I gave it a quick try but my hex uploader (avrdude) is misbehaving at the moment. I’m probably getting the timing wrong or something.

I echo the sentiment of @MLXXXp though: I don’t like uploading things if the code isn’t available (hence I only have a rudimentary command line hex uploader). Not so much because of security, but because I find compiling the source more convinient and can check which areas of EEPROM are going to be overwritten.

(Felipe Manga) #14

Do you look out for anything specific in source code? Or is it more of a “opensource only” policy?

(Scott) #15

Mainly make sure the code doesn’t contain errors that cause it to continually write to EEPROM, which would quickly exceed the maximum write lifetime.

Also, if I spot any direct access to hardware, I check if it’s safe. For instance, if the code were to set a pin connected to a button as an output and set it high, pressing the button could short out and damage the pin.

If EEPROM is used, I check if it’s writing to the first 16 bytes reserved by the library, so as to avoid having a programmed Unit Name or Unit ID or other system settings clobbered.

(Felipe Manga) #16

Ah, I see. Makes sense.
Is the short a problem on the 32u4? I’ve shorted pins on 328s without issue.

(Scott) #17

Although these processors are quite robust, shorting output pins, thus exceeding the maximum current ratings specified in the datasheet, could potentially cause damage. Damage could be accumulative, so it may take some time for problems to appear.


(Scott) #18

I should also add that because I use Linux, going to the trouble of extracting a .hex file from a .arduboy file, and then using the command line in a terminal window to upload it, is more difficult for me than loading and compiling the source.

A less skilled Linux user may not even be able to play the game at all.

(Michael) #19

To my knowledge, none of my games have caused any damage.
The only suggestion for the last game i released, Omega Horizon, was how i was accessing sound on/off.

…But I understand the need to be cautious, i plan to upload the source code for those who prefer to compile the code this evening when i get home.

(Pharap) #20

As far as I know apart from that one incident a little while back (which I think was due to the hex being compiled for the wrong board) there haven’t been any cases of a hex causing damage to or bricking an Arduboy. (And I think that case also involved the lock bits not being set, I’ll check at some point.)

The chance of someone causing damage is slim since most people aren’t playing around with the pins or writing their own hardware controlling code, but overwriting EEPROM is certainly a concern.

A number of people in the past haven’t been aware of the convention of skipping the first 16 bytes, and even more people choose to write to the earliest section of EEPROM, which (depending on how good the EEPROM’s built in wear levelling mechanism is) could cause the earlier area of EEPROM to wear out quicker.
More importantly, it means a lot of games end up overwriting each other, which is why some people resort to EEPROM save/restore programs, but that has the side effect of using up EEPROM read/write cycles quicker. Granted progmem is more likely to wear down faster than EEPROM, but I for one like to be careful, so sometimes I modify games to move the EEPROM save location.

I suspect in your case you aren’t actually using EEPROM yet, but it’s something to be aware of.

Ultimately I prefer the code to be available anyway to make bug fixes quicker and to encourage more people to make their source code available for others to learn from (which is half the point of the Arduboy in the first place).