Wip game 'Cactusman loves diamonds'

I’m working on an action puzzle game. At the moment called ‘Cactusman loves diamonds’.

I’ve worked as a gamedesigner on a couple games, and wanted to challenge myself to make an original game for the Arduboy. Including the pixel art.

Here is the first concept screenshot:

Your goal is to collect all diamonds as fast as possible. If you run into a slime, ur dead.
Slimes move horizontally. Slimes with glasses are smarter, and turn around towards you if you cross their horizontal path. Slimes with headphones (Lucius ;)) move faster than you.
When a slime touches a diamond it is cut in half, and looses half it’s value. If it touches a diamond 2 times, the diamond disappears.
So it’s essential to get to the diamonds as fast as possible.
By pressing the A button, you can perform a boost, that launches you in a straight line until you hit a wall. But watch out to not run into any slimes.
The game will have multiple levels and highscores to beat.

I have 3 questions for you guys:
-Is it possible to make the level 2 screen sizes tall, with multiple enemies, can the arduboy handle that and smoothly move between the two screens? I’ve seen some RGP games, so I guess yes?
-Is it possible to use white/black/gray colors? I’ve seen a rpg game that seemed to have that working, this would increase the possibilities with the pixel art enormously. Does this work well at this point? How is it done?
-Is it still possible to get a dev unit on short notice? Or someone located in Amsterdam interested in a meetup to run a prototype?

Let me know what you think so far :). I’ll keep reporting updates here.

Latest image in this topic

1 Like

Yeah, it’s totally possible. Do you want it to scroll when you get closer to the edges of the screen or do you want it to just change like it’s changing to a different room? Both are completely possible, especially with how simple your game seems like it will be.

[quote=“Thonis, post:1, topic:1970”]
-Is it possible to use white/black/gray colors? I’ve seen a rpg game that seemed to have that working, this would increase the possibilities with the pixel art enormously. Does this work well at this point? How is it done?[/quote]
So, there is no way to make gray on the screen… Only black and white. BUT, the screen’s refresh rate is faster than any human can detect, so it’s possible to flicker between both black and white real fast to create gray.

For instance, if you had the following two images switching between each other every frame, the face would stay black, the background would be white, but the hearts would appear to be gray.

← >

This would obviously be a decrease to how many frames you are limited to animating your game. It also takes a lot of resources, so it’s pretty much not a feasible method for displaying game sprites on the Arduboy.

I don’t think so…

Thanks for the answers!

About the grey pixels, would it be possible for example to do this on the title screen only, and still have high fps performance on the main game?

Hmm sounds like there are really few devices around. Is the dev unit still being made, or now everybody just needs to buy the normal one?

On another note, what do you guys think about the game concept so far?

Sure.

I think you’ll need to buy a normal device. I can’t speak for the Arduboy guys, but you might ask if they could send you a device a bit sooner as you’re making a game.

Looks nice.

The production version is better than the DevKit in almost every way, so why would you want a DevKit?

If you install Arduboy board support in the Arduino IDE, the Arduboy library will support both. If you want to do different things for each type in a sketch, you can test the AB_DEVKIT define:

#ifdef AB_DEVKIT
// Code for Dev Kit
#else
// Code for production Arduboy
#endif
2 Likes

WIP title screen, to give an indication of the game’s vibe.

Still needs a lot of work, will share the process here.

2 Likes

Haniwa faced cacti are best cacti.

Time for a little ‘paper prototype test’ if you have paint, ur welcome to draw ur path on this level image below:

How would you grab all diamonds as fast as possible?
(Spikes and slimes kill you. Slimes move horizontally. When slimes touch a diamond it breaks.)

Im currently thinking of making the levels 2 screen sizes high.

1 Like

I guess it would depend on if the slimes have set paths or not…

@crait Thanks for the feedback. I still doubting if slimes will have fixed horizontal only paths, or if they will move around freely. But this type of details I can only answer with playtesting. Waiting for a Arduboy to arrive to tweak gameplay. But still enough to do before that stage.

Btw anyone here living in Amsterdam with an arduboy that we could borrow for coding/testing?

If you’re going to go with random movement, in my experience the best way to handle random movement is to make the creature move in a single direction for a set number of steps/over a set number of frames, wait a while, and then do the same in a (possibly different direction).

Moving in a fixed pattern is generally cheaper but also less of a challenge for the player unless you let the creature attack the player when the player is in the creature’s line of sight. It depends on other factors though, like whether or not the player can fight back and how much damage the player can take.

My solution. I don’t know if it’s the quickest, but it’s probably one of the safer options since it minimises potential slime contact.
Note that the cyan path has to be the player’s first path because it’s the only gem in risk of being destroyed by a slime.
Also I’m making assumptions that the slime at the bottom moves out of the way enough for that to be a viable path, otherwise the player would have to backtrack up to the top left.

1 Like

Thank you for the feedback!

I’ve chosen to make the game with 12x12 sprites to have more of the level in your screen. But this also forces me to use a boarder less white on black background sprite style.
I’m considering doing the next game in a 16x16 sprite size, with a line boarder sprite style with white as a fill/background color.
Bit hard choice but will stick with this for now I think.

12x12 Tiles means you’ll have left and right padding of 4 pixels and top and bottom padding of 2 pixels.
(Just in case anyone else is too lazy to work that out.)

@Pharap why would there be left and right padding? I understand the vertical padding of 4 total pixels (wherever you put them) because the bits are stored vertically in the buffer. But each tile could just be 12x16 pixel images?

I think he means that the screen is 128×64 and 12×12 tiles can fill area of 120×60 which leaves 4 pixels to both sides and 2 pixels to top and bottom. If the game world is scrolling, then that doesn’t need to happen.

1 Like

128 does not divide evenly by 12, so as @Tomin kindly pointed out, there would be 4 pixels left over each side. Whether that’s padding or whether the world overflows the screen is a different matter, but the uneven division still stands.

Also, rectangular tiles would be very irregular (if you’ll excuse the awful pun).

Oh I meant the tiles would be 12x16 but only drawing 12x12 since images need to be multiples of 8 vertically.

Rectangular tiles would be irregular haha. Could be interesting though.

For me the choice was between 16x16 (preferable) or 12x12.

Because initially I wanted to create a game that would fit in 1 screen, I choose 12x12. Now the idea is to make levels that are 2 screensizes tall. So it will have some boarders on the left and right of the screen.

1 Like

Animation of the player character. Quite head breaking to fit in 12x12 pixels :scream: :slight_smile:

update
And the enemy animation

2 Likes