[WIP] Sensitive

(spinal) #1

OK, I don’t often finish coding games and this is no exception. I have however got it to a point where I’m happy to show off about it.

It’s my Arduboy remake (demake?) of my fav. C64 game Sensitive by Oliver Kirwa.

I couldn’t get a decent video of it running because I’m doing very silly things with the screen, but I did manage a couple of photos.

The title screen has two shades of grey and the levels have one shade.

Here is the source for anyone who wants to test it out on their Arduboy.


I thought this would be the first ‘grey’ game, but Remz beat me to it with 'Ard Drivin.

On the technical side, the music uses A.R.G’s music lib. The greys are done with screen flickering. I used a slightly different method to Remz, but trhe effect is still the same, approx 67fps to line up as good as possible with the screen refresh.
There doesn’t seem to be any delay at all when refreshing the screen, so we don’t have any vblank time to play with, so the GFX are done as fast as possible, all 8x8 tiles rendered by hand, with the exception of a single sprite.
A nice small 3x8 custom font to fit the required information on screen.

To Do

  • Loop the music
  • Add more levels

Tell me what you think!

New (another) unofficial repo :)
New (another) unofficial repo :)
(Marco) #2

30/3 will be the GRAY THURSDAY.

(Josh Goebel) #3

Neat. Flicker is pretty apparent on my unit. Also you should be able to try a puzzle an unlimited # of times. I don’t think your lives should be finite. Just my 0.02.

@spinal I also figured out how you could use the existing frame stuff to get your greyscale timing much much more consistent. Hit me up on chat if you want to know. Essentially your frames need to run a little “fast” and then your padding needs to be at the beginning of the loop, not the end.

arduboy.setFrameRate(130); // slightly faster than you want
  if (!(arduboy.nextFrame()))
  // at this point we're an even 7ms lets say
  // at this point we're at an even 7.657ms and we need to draw NOW

  // code goes here to prepare the next frame for rendering in 7ms or so

This all presumes that you’re only using 50% CPU black/white to allow for 100% CPU for greyscale. If your loop is too slow then your timing will always be off. You can test that with the new function built into the library that causes the LED to light up if your code is too slow.

And of course this code knows nothing about greyscale… you’ll just be drawing white/grey/white/grey frames at ~120 FPS which will end up around ~60FPS.

(spinal) #4

The title screen will flicker a lot more as it’s using 3 frames for an extra grey. It doesn’t work weel enough for that, just an experiment.
As for the number of lives, I disagree, infinite tries would make the game far too easy imho.

(Josh Goebel) #5

I’m pretty sure we did 3 shades pretty smoothly before - although not as smooth as two, for sure. Let me add a 3rd shade to my demo and see what it looks like perfectly synced.

(Holmes) #6

Circuit Dude let’s you have infinite lives. :wink:

(Josh Goebel) #7

I know. And thank god for that. :slight_smile:

(spinal) #8

Not much in the way of comments, I assume nobody likes this (style) game?

(Nicolas Mougin) #9

I had not tried it…

Just did, and wow :wink:
That’s really the kind of games I like: good puzzle game with awesome intro music.

It took me some time to get the gameplay but now it’s real fun. And the gray really adds something to the game.

Congrats! Really like it!

Just a small improvement would be to either remember the last level you played and resume on next game, or be able to select the level from the intro screen.

(spinal) #10

The intro music will loop some day, probably once team a.r.g add reloading music into their tracker, it’s not fun recomposing the music every time I want to change a bit.

how is the flickering? is there any?

(Nicolas Mougin) #11

There’s flickering in the intro screen, but not during the game.

(Holmes) #12

I LOVE these kinds of games, but I just have been too busy to test it out. It’s on the top of my list. :wink: I’ll play it tonight and leave some good feedback.

(Celine) #13

How’s the WIP? Im excited to try the final game :smiley:

(spinal) #14

All it really needs is for the music to loop. The gameplay is finished and there are plenty of levels.
Please don’t let the. ‘wip’ part prevent you from enjoying a great game.

(Take That For Data❎) #15

Flicker in the intro screen is more apparent than when playing but noticeable no matter how you slice it.
I would like more contrast between the player and the background but maybe that makes it too easy


If you recreate the music in the editor (yes I know … again) and you save the file as an .atm file and post it here (or a link) I’ll help you making it loop. I need the saved .atm not the exported .h

(Rem) #17

Hi Spinal,

Congrats on the game, well done, smooth, polished, great music, and fun to play! (Of course I’m going to “cheat/edit” the code and add of couple of lives because I want to see all the puzzles :))

Your grayscale title screen looks great and antialiased. The bottom half part flickers visibly, but could be made to be “by design” as a sort of sci-fi look.

I love your fullscreen fades too, using screen brightness.

Overall your grayscale technique shows the same “moving scanline” glitch than mine in Ard’ Drivin’. Is it a coincidence we both ended up at exactly 67 fps?

Will the game itself have sound effects?

(spinal) #18

The title screen flickering is because it takes too long to render. For 4 shades, you need 3 frames and of course a much higher refresh rate. More lives is simple enough, just comment out the lives–; in movePlayer().
I don’t currently have any intentions of adding sfx to the game, I think it’s OK the way it is :slight_smile:

(Josh Goebel) #19

No, because you’re trying to match the hardware refresh rate… but you can also change that by asking the OLED to refresh at different rates… so if you wanted closer to 60fps you can have that also. I keep the OLED PDF handy for reference.

(Michael Gollnick) #20

For the title screen you could optimize the following loop:

for(char y=0; y<3; y++){
for(char x=0; x<14; x++){
int mt = pgm_read_byte(titleMap+(x+14*y)+((frameNumber%3)42));
drawTile(x+1,y+3, titleTiles + (mt

to something like that:

uint8_t currentFrame = (frameNumber % 3) * 42;
for(char y=0; y<3; y++){
uint8_t yOffset = y * 14 + currentFrame;
for(char x=0; x<14; x++){
int mt = pgm_read_byte(titleMap+ x + yOffset);
drawTile(x+1,y+3, titleTiles + (mt*8));

It should give it a boost in speed. Did not compile it, just in my head.