Rogue-likes! Artist seeking Coder!


#1

Hello all, new to the community. Not a programmer, but well versed in graphic art and design (and an old school gamer).

So, I believe the Arduboy can be the ultimate portable rogue-like system. (Rogue/Moria/Slash’em/Nethack?)

I would love to contribute to the development of an Arduboy Rogue-like with design/bitmap art and see it to final completion.

So I have two questions with VERY MINIMAL UNDERSTANDING of programming for the Arduboy… would it be better to design a micro font (if this is actually a resource used) or individual bitmaps of the ascii characters to be converted to binary/hex values? Second question is if the oled has any unused pixels that wont display?

Thanks and hope to team up with a coder(s) to make this happen! :slight_smile:

EDIT:

Based on a 6x8 character… Example “a” and “A” and a “selected/targeted” overlay icon:

“a” on screen = ant?

“a” selected for targeting with wand/zap/throwable

“A” higher class beastie = Antlion?

“A” Antlion selected:

Targeting overlay for selected sprite:

Would there be too many sprites for Arduboy or is it the way to go? Hipshot guess but that could be around seventy plus 6x8 sprites plus a “targeted” overlay minus the actual coding… I know memory is quite limited!

Thoughts? I have no doubt some rendition of this genre can be done, but i am lacking in the scope of possibilities due to memory restraints… hope this all made sense!


(Mike) #2

II don’t think there’s a clear technical advantage to either bitmaps or fonts; both require a support library and there are reasonable options available. So the choice probably depends on your game design goals. The sprite libraries are designed for arbitrary placement on the screen and animated characters that change as they move. Fonts are designed for working with a grid of monosized characers that don’t overlap, you have to do animation “by hand” like the original rogue-likes.

Space shouldn’t be much of an issue either way as well. 70 8x6 characters is 420 byte, or 840 bytes double-buffered, out of 32K of flash. Rogue was originally developed on a 16-bit mini with 64K of address space, and ports ran on the 8-bit micros that followed, with 48K or less of program space. so I’d say it was a good fit that way.

The interesting part will be adopting the UI, though I’ve only seen it on either a keyboard or a touch screen.


#3

Thank you Mike, that helped me more in understanding of the difference between ascii and bitmaps. Seems like a font is the way to go.


(Josh Goebel) #4

I thought about porting Fargoal but the C code I found is pretty messy and hard to read.


(Josh Goebel) #5

The harder part is storing/generating the maps for every level, not the fonts/graphics. A simple tileset doesn’t take up too much RAM (as already mentioned).

Nethack might actually be great if you could find a version to compile in 20kb or so… then you just have to figure out how to deal with such a tiny screen.


(Nigel Scott) #6

One feature of roguelikes is that the maps are procedurally generated, so you wouldn’t need to store any maps.

There is a version of the original Rogue (IV) on the GP32 which works really well with a D-Pad and two buttons. Unfortunately I can’t find the source for it anywhere, but it might be a useful reference for the interface…


#7

@fuopy is/was working on one


#8

Maps would need to be stored though, procedurely generated going down in levels, but still have to be there (same level generation) getting back out.

I think there is a grand place for this genre though.

What about slash’em? Seems like the gameplay would match the arduboy better. A bit quicker/hack-n-slash random dungeon crawler.


#9

Love Madgardens Fargoal for ios. Wish he finished Fargoal 2. Died years ago even after a kickstarter…


#10

I actually meant iLarn, not slah’em…

played the heck out of roguelikes on the palm pilot. Thank you Bridget Spitznagel!!!

http://roguelike-palm.sourceforge.net/iLarn/


(Josh Goebel) #11

Rambo, too funny…


(Nigel Scott) #12

If the map can be procedurally generated once, you’ll get the same map next time from the same seed. No need to store anything - that’s the whole point of procedural generation. :wink:


(Mike) #13

But the map going back up is after the user has played through (part of) it. So they need to be stored.

On the other hand, going back up is (in the version I’m familiar with) an end-of-game event or impossible, so could well be left out.


(Josh Goebel) #14

If the fog of war and items have to be stored for 100 levels, no way… but it is possible to rebuild the maps from just a 16 bit int seed. You’d just have to reexplore them to get out… not sure if that’s how the originals worked or not.

Did the original keep your progress so you just walked thru the maps easily on your way out?


#15

Progress/maps were saved once generated. you could go up and down floors and they would stay the same.