Roguelike port?


so are the current enemys shown using the same 4 colors?

goblin green, bone white, oak brown, tin grey


Yes, both of them are using the same colors.


I am leaving this for today with the mockup in different popular color palettes (+ our floor color).





If I won’t hear otherwise from you guys, I will go with the palette I was originally working on (but change some colors we are not using, to some more useful ones).


I’m not sure how I feel about multicolored entities, but I’m not a big fan of the yellow-tinted palette. I prefer the bolder colors of the original.


i agree on going for bolder colors, though everything is prety nice, since i cant test it on hardware it might be best to go with what these lcd’s are good at

now back to programming and the long path of implementing the classes, how we do that?
i was never sure how too implement them properly so there logical

also some renaming or refactoring of code needs to happen since we aren’t using any standard way of writing functions

if someone works on classing the ai/enteties
i can do the direct graphics


Thanks @adekto and @wuuff for the feedback. I will try to finish the bolder palette thing today and then continue on the design doc. Are you guys ok with me creating the “RPG” mechanics for the game (character stats etc.)?

As for the multicolor sprites. I am also on the fence.

Adding them makes the character “pop” more on the screen and makes the sprites look different to Oryx’s tileset (which apaprently every other new graphical roguelike uses and it would be good to stand out a bit).

But, if we add them we are losing the zx spectrum/ASCII vibe, which I quite like.

A middle ground approach would be to redo some sprites. The Player Character Sprite and the bloated zombie are the biggest offenders, as I made them when I was only looking at Oryx’s stuff, before I did all the 80s micro computer fantasy games research.

In the meantime, when we were all asleep, it seems that Lord Mort ordered new stone tiles for his dungeon. Tiles are very in this season :stuck_out_tongue:

I think they look better than our previous ground, and are not too bad when it comes to the black background around the sprites. I can probably lighten them up a bit, and they would still be ok.


I think getting a standard for naming functions/variables would be very helpful. I think that should be the first thing. If you make a standard, either I can add it to the design doc or I can give you editing rights so you can do it.

I am in the dark about implementing classes. We can try summon @trelemar see if he is up to the task.

If not, I can do some research later today into how other roguelikes are dealing with this. This might point us to some solutions.


Here’s a first pass at the full palette (minus color 15, because I am not sure what we could add). Second row is the basic colors, above is one step lighter, below two steps darker. Black would not change (we have blue-ish and red-ish gray available for grayscale if needed).

Most of the game would use the basic palette (second row/big squares).

Some ornaments could use darker (bottom) color by default, just to signify to the player that the tile is simply ornamental and not interactive.

Light colors would seldom occur for long periods of time. They can be used for animation by color shift (lava, water or occasional flash of light?)

Let me know what you think. What would you like me to change etc.

@adekto: once the pallette is implemented as RGB codes, how much of a pain would it be to change? As we might need to change some colors if they are not working in-game/on actual hardware.


color values arent a problem but pallet order is so basicly if you set it up as red green magenta it would prefrebly be in the same range so not all the graphics get mucked up


considering if posible (but might be to much data)
a rudiment conversation system to enemy’s and npc’s
would be part of the rpg like stats (charisma roll) to convince enemy’s to surrender or pay up or trade

npc in the town could work with similar system but more fleshed out since that level might be hand made

also this is where portraits could come in for important npc/enemy’s

in addition bosses could have a opening line wen they are encountered using the same text system


Great, I tried to setup the the color order so the colors can be hue shifted if needed to left and right. I might tweak it tonight a little and you can implement it. We won’t be changing the order after that, but we might tweak the RGB values a little once we see how they look on the screen.

I think talking to enemies would take away from the core gameplay, but having some NPCs or Bosses be talkable would be a good addition. We can also use the conversation system for some “choose your own adventure” elements during the dungeon runs (shrines etc.).

I will add some explanation of the conversation/choose your own adventure system in a while.

Charisma can also be responsible for discounts to shopping and some conversations between dungeon-runs.


yea so im not sure how the pallet would work how you say it would work

the formating i had is 0 is always black so we index on 3s or simply put we offset the pallet on 3
so shared colors is posible but they have to be maped adjacent to the others


It might be because I was thinking of storing it in tables/arrays.
There is one table for basic colors 0-15 (black, grey, brown, red…)
Then inside each index is another table 0-4, where 0 is the lightest color, 1 is the main, and 2 and 3 are shades.

Then if we need to call the color we call colors_table[MAIN COLOR INDEX][1] to access the main color. We can turn light/shadow by manipulating the second index.

But this is me coming from pico-8. You probably have a much better solution. I am happy to re-arrange the color in any way you would prefer.


im not even talking about shades but color order, most compact i got is just a color pallet
for the luminance i think we might be able to add suptract from the base color by a amount with a “grayscale table”
idk if that works on 565 colors have never tried it before

but the problem i got is this all stacks up, every sprite has a backed in pallet index (on flash), and every screen tile has a luminance index (on ram)


Wait, so you don’t want to use the included steps (1 up, 2 down) that I made for the light effects? Because I am using some of those secondary colors for things (e.g floor, table & chairs below)

I think going with those pre-designed colors would give us more control.

Anyway, tell me how to arrange the color palette so you can use it, I will re-arrange it and it will be our official order.


yea no luminance is like a post effect
so the way to order the colors needs to be based on the sprites
like skeletons and goblins can share the same color sectors of brown and grey

edit i have a better system in my head
so since its 16 colors means we can split the byte in 2 so giving us to index points
its still a bit messy and we need to be carefull about color orders but means we got 1 color and a 2 color selector


Ok, if luminescence will be done with code, we really just need the basic colors. The rest will be done at runtime, right?

Won’t that be too memory intensive for pokitto?

I am getting a bit confused, because I assumed we are doing the colors completely differently.

So basically, the colors can be in any order, as long as the order won’t ever change?

OR, Can’t we just give ID name variable to each color instead and call it by color, then order won’t be a problem.


problem is memory, want it as small as posible
since ech sprite will store its color index that stacks up

also if we would refrence every color seperatly we add a hole byte for that 3rd color, wich multiplies by all the sprites
so after 30 or so tiles we waist a hole tile weurth of bytes we could have used if we optimized our color order


Ok, so how would you like to optimize it? By usage (how often we use it), by luminescence, by hue?

Also, do I need to organize the secondary colors or are we scrapping everything past main 16?


ok so its 16 if you want to select your colors individualy using 2 selectors wich like this A selector 0-16, B selector 0-15 and B+1 selector 1-16
sorry if i make it hard to explain

as a aditional since we know wich color 0 is on all tiles we can basicly drop it out the pallet giving you 1 more color

so these color picker are part of the sprite data (on flash memory) the hue since it has to be calculated due to the lighting thing you wanted, so thats stored in a little tile buffer (on ram memory)
if it wasnt clear, every color in the tile will become lighter or darker by the same amount

also if its biger then 2 bytes we might aswell 332 rgb inside the tile themselves wich i dont recomend but give you basicly 255 colors. just pointing out it exists but is not the best