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
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 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
I think I am getting it, but aren’t we over complicating things? Would the buffer be more memory efficient than double indexes?
Why won’t we just store the colors under indexes 0-X (X is our total number of colors I will use to make tiles, right now we are aiming at 16 or 64 if we include the secondary colors).
Tiles would be made with indexed colors. So when you read them, they have the colors already baked in.
When they go into light/dark we just changed what color this tile displays. Instead of color [3][2], it would change to [3][3]. This would also give us to what colors are displayed, instead of letting the system do it, which might end up making some ugly colors.
…
You are the programmer, if you say the color generating by code will work, I trust you. Just let me know how I need to store the palette for you to use effectively, and how should I make my tiles
the problem with the color[x][y] is that it mutliplies the memory amount
ech color is 2 bytes in size, x16 colors x4 gradiants thats like 128 bytes
wile with the optimized on the fly gradiant thing i can give you 64 colors with that memory and even have more then 4 gradiant depths
Can you control how you will generate the gradient depth for each color? Because some of the 64 color palette secondary colors have been hue shifted by a little to make a more interesting color. I am just worried we might end up with a lot of muddy colors if we just change RGB or HSL by X amount on each color.
theres to concept of hue with this so no, there is a way to do it but it ends up needing more data that im trying to save so it would not be easy to do
there other problems with the weights on these values of light, like if the light source is one tile ofscreen it wont be evaluated, there is no concept of raycasting atm in there so it lights up trough walls
first iteration on these hole thing will probbely only be the player thats the light source
im sorry man but sacrefices have to be made to fit all the tiles in and have room for all the diferent ai and mechanics
this is why facing of enteties isnt in the game
but is 16 colors not enugh? technicly you get 17 due to the optimization (since black is default 0)
After all, we are far away from 256 tiles (we are at around 100).