Nice! I like the way the platforms feel like they're kind of intentionally floating? Not just because that's what video game blocks do, but because they're platforms... that float.
Don't trust pixel suns though, they're up to something
Dots Of Differing Colours: The Pixel Art Thread
Excerpt from RPGClassic's page on Legend Fantasy of Generica I (Gameboy):
-There's a bug in Placeholder Town where the NPC Guard near the entrance says a line meant for the final boss if you talk to him too many times.
-Did you know that the Nameless Hero's hair had its own sprite? It's true! For the longest time I thought that was some kind of fancy hat or helmet, but I dug up a Nintendo Power interview from the game's release and the developers confirmed that that was actually supposed to be his hair. Who knew?
-
- Site Admin
Ah, of course... Legend Fantasy of Generica I's infamously eye searing carpet tiles. Good job on the shadow tiles there, and the cracked brick tiles... The big crack could probably have done with less shading, though, just darkest colour.
Ehehehe... A bug, they say. Obviously, they never cross referenced with Legend Fantasy of Generica IV on the SNES.
Ehehehe... A bug, they say. Obviously, they never cross referenced with Legend Fantasy of Generica IV on the SNES.
The first NPC you meet actually being the Dark Emperor Darkmonius and also from alternate dimension Mars was one of the top five video game twists of its day. Later games in the series tried to copy that twist but it didn't work as well because the audience already expected it.
Here we are, art assets ripped from a recently uncovered canceled Anime Alchemist Game for the Gameboy. Who knew that Gust was operational back then?
Really, though, this isn't perhaps precisely what the challenge asked for, but I think it's in the spirit of it well enough. That, and I was kind of running out of time.
Oh, and for some reason, I really just couldn't get used to the GB Green Palette so I bent the rules a bit and used the grayscale palette.
As you can see, it is designed on a tile system, though there's definitely a large amount of unique tiles in just this scene alone.
The flag (3 tiles, l-shape) and Ayesha (2 tiles, 4 with staff- she does actually fit in a 16px width) would be mapped as sprites, while everything else is tiles.
As an apology for not having a Pana sprite, here's a look at some of the iterations I did earlier when I was leaning towards a SaGa style.
Really, though, this isn't perhaps precisely what the challenge asked for, but I think it's in the spirit of it well enough. That, and I was kind of running out of time.
Oh, and for some reason, I really just couldn't get used to the GB Green Palette so I bent the rules a bit and used the grayscale palette.
As you can see, it is designed on a tile system, though there's definitely a large amount of unique tiles in just this scene alone.
The flag (3 tiles, l-shape) and Ayesha (2 tiles, 4 with staff- she does actually fit in a 16px width) would be mapped as sprites, while everything else is tiles.
As an apology for not having a Pana sprite, here's a look at some of the iterations I did earlier when I was leaning towards a SaGa style.
-
- Site Admin
Mmmm, yeah, that's pretty good! I remember you showing the rough to me, and I really enjoyed it, and this finished work... Yeah, that's some good pixel work. And those legs... Actually, I see that leg pose a lot, and I've never fully understood why... Ah well, that's a good tileset. 
Eh, the leg pose is her being being pigeon-toed, (the colloquial name for overpronation of the feet,) basically where someone stands with their feet pointed inwards. Some point along the line people interpreted it as being cutesy or an indicator of clumsiness, which has made itself a rather deep-seated thing in media these days.
It does have the potential to be a medical issue, just like being duck-footed, but really only if you walk and run with your feet in such a stance. Some people develop pigeon-toeing or duck-footing naturally, usually from an early age, (typically being the stance they find has the best balance for them when learning to walk,) but can also be something that develops later. I'm duck-footed, for instance, always have been, but I learned run and walk straight late, so about the worst thing that's happened is that my calves are somewhat rotated and curved. It can also have some effects on development of muscle in the leg, just as notable side-effect.
In short, she has her legs like that because they're like that in-game, and if I'm going to do fanart, it might as well be faithful.
It might be a bit hard to see, but that's the only reference image I have at hand. It's not amazingly pronounced, but y'know, when you've only got 16 pixel width, you make the best of it.
Ayesha's also got platform shoes, which I tried to get across as well.
It does have the potential to be a medical issue, just like being duck-footed, but really only if you walk and run with your feet in such a stance. Some people develop pigeon-toeing or duck-footing naturally, usually from an early age, (typically being the stance they find has the best balance for them when learning to walk,) but can also be something that develops later. I'm duck-footed, for instance, always have been, but I learned run and walk straight late, so about the worst thing that's happened is that my calves are somewhat rotated and curved. It can also have some effects on development of muscle in the leg, just as notable side-effect.
In short, she has her legs like that because they're like that in-game, and if I'm going to do fanart, it might as well be faithful.
It might be a bit hard to see, but that's the only reference image I have at hand. It's not amazingly pronounced, but y'know, when you've only got 16 pixel width, you make the best of it.
Ayesha's also got platform shoes, which I tried to get across as well.
-
- Site Admin
Well, almost time for the next month's challenge, and... Hrm... Trying to get a balance of mixing it up while keeping them accessible for any new folks that might appear (If you know of any folks who enjoy or would be interested in sprite art, invite 'em to the thread, the more, the merrier!)
Oooh, I know... Let's almost have the constraints of the NES! I'll edit with the necessary palette later on, but here's the challenge!
SEPTEMBER CHALLENGE!
The NES was an interesting one, as it only technically had a 16 colour palette. In actuality, it had 13, split into three separate, four colour palettes.
"Wait... That makes 16!"
Yes. Yes it does. Except all four palettes had to share a single "background" colour. But it's okay, we don't actually have to worry about that, because that would overcomplicate things. So, 4 colour palette again, picked from the NES one, and this time, we're doing... A run cycle. Run cycles are a nice fun one, because you can play tricks with them pretty well. They run the whole gamut, generally between 2 and 8 frames (yes, 2 frames minimum, and that was what was actually used in the first Super Mario. And the first MegaMan. I can't remember if the first Castlevania had 2 frames, but I suspect so.) And we'll be going with the 16px height, 8px width for this one. Please upscale by... 1600% sounds nice, would look fine on the forum, and give us a nice clear look. Remember, Nearest Neighbour is the method you want to use for resizing, always resizing by a power of 2, and if your resizing only goes up to 800% , then 800%, then 200% will do it.
"But Jamie, er... I can't do animations. My paint program doesn't do that."
Ah. This is where I have failed you. I've failed to link good free pixel art programs in this thread, and I most heartily apologise for that oversight!
10 free pixel art programs!
When I was using free programs, rather than Aseprite (£10, and a damn fine pixel art program!), I most enjoyed Piskel, but, as far as I know, they're all good, so... Go hog wild!
Anyway, to sum up: A character animated running, 2 to 8 frames, using four colours from this palette:
Yes, because with the exception of 1-bit generally being black and white, and the gameboy palette, a palette for a 8 bit or 16 bit machine is much larger than the number of colours it allows you to use. This is also why I will probably never try to challenge you with VGA or SVGA. Because it's not all colours... But both of them have a lot of colours to pick from...
Oooh, I know... Let's almost have the constraints of the NES! I'll edit with the necessary palette later on, but here's the challenge!
SEPTEMBER CHALLENGE!
The NES was an interesting one, as it only technically had a 16 colour palette. In actuality, it had 13, split into three separate, four colour palettes.
"Wait... That makes 16!"
Yes. Yes it does. Except all four palettes had to share a single "background" colour. But it's okay, we don't actually have to worry about that, because that would overcomplicate things. So, 4 colour palette again, picked from the NES one, and this time, we're doing... A run cycle. Run cycles are a nice fun one, because you can play tricks with them pretty well. They run the whole gamut, generally between 2 and 8 frames (yes, 2 frames minimum, and that was what was actually used in the first Super Mario. And the first MegaMan. I can't remember if the first Castlevania had 2 frames, but I suspect so.) And we'll be going with the 16px height, 8px width for this one. Please upscale by... 1600% sounds nice, would look fine on the forum, and give us a nice clear look. Remember, Nearest Neighbour is the method you want to use for resizing, always resizing by a power of 2, and if your resizing only goes up to 800% , then 800%, then 200% will do it.
"But Jamie, er... I can't do animations. My paint program doesn't do that."
Ah. This is where I have failed you. I've failed to link good free pixel art programs in this thread, and I most heartily apologise for that oversight!
10 free pixel art programs!
When I was using free programs, rather than Aseprite (£10, and a damn fine pixel art program!), I most enjoyed Piskel, but, as far as I know, they're all good, so... Go hog wild!
Anyway, to sum up: A character animated running, 2 to 8 frames, using four colours from this palette:
"That's... A lot more than 16 colours."The NES Palette wrote:Black: #000000 ... Obviously.
#797979
#a2a2a2 (When you see all repeating numbers, it's a gray. Remember, RGB)
#305182 #4192c3 #61d3e3 #a2fff3 - The... Pinks?
#306141 #49a269 #71e392 #a2ffcb - The Tealish
#386d00 #49aa10 #71f341 #a2f3a2 - The Greens
#386900 #51a200 #9aeb00 #cbf382 - The... Oranges?
#495900 #8a8a00 #ebd320 #fff392 - The Browns
#794100 #c37100 #ffa200 #ffdba2 - The Reds
#a23000 #e35100 #ff7930 #ffcbba - The... Russets?
#b21030 #db4161 #ff61b2 #ffbaeb - The Dark Pinks
#9a2079 #db41c3 #f361ff #e3b2ff - The Purples
#6110a2 #9241f3 #a271ff #c3b2ff - The Blues
#2800ba #4141ff #5182ff #a2baff - The... Other Blues?
#2000b2 #4161fb #61a2ff #92d3ff - Yet More Blues
#797979 #b2b2b2 #ebebeb #ffffff - RETURN OF THE GRAYSCALE
Yes, because with the exception of 1-bit generally being black and white, and the gameboy palette, a palette for a 8 bit or 16 bit machine is much larger than the number of colours it allows you to use. This is also why I will probably never try to challenge you with VGA or SVGA. Because it's not all colours... But both of them have a lot of colours to pick from...
Well this isn't entirely true. All three of those actually use three frames of animation for walking, (although CV1 technically does re-use the idle stance as part of the Simon Shuffle, so it is partially correct that it only has two frames). You're not going to have an easy time making a 8x16 walking cycle with just two frames. (Metal Gear does pull it off, though it's pretty goofy and it's also a top-down game.)
For reference:
This isn't to say that you can't have a two frame walking cycle in general, that was very common for top-down games on their horizontal movement frames, as exemplified by LoZ 1 and FF1. Said games also usually just flipped the sprite horizontally for moving up and down. Same goes for Metal Gear in this case, because it's a top-down.
I'm still working on my animation, but given my love for retrotech, I might as well talk a little bit about the constraints you'd be under when actually developing for the NES and the Gameboy.
The Gameboy came later and in some ways is more capable than the NES; we only have four colors to work with and we can use them all at the same time, of course. However, it also has its own palettes as well so you can do things like my night-to-day transition without needing two copies of your graphics. You can even make some of the four colors overlap if you wanted details to gradually emerge, or to do a fade to black or white.
The fundamental unit of graphics on the Game Boy is the 8x8 tile, and you had 384 of them to work with: 128 reserved for background, 128 reserved for sprites, and 128 shared between both. This lived in a chunk of RAM that could be copied to out of the cartridge ROM as needed. There were two map areas into which you could place background tiles, each noticably larger than the whole screen, and the hardware let you set it up to display two parts at once; the main background, and then a separate chunk (bound to an edge) that covered things like status windows. That meant that you could have a fixed status window on the bottom or the right of your screen and then have an omni-directional scrolling window over the main map, all without having to do more than just asking the chip to arrange the screen that way.
But that's 1989 tech. The NES was designed in 1983, and the idea of what videogames were even for was a lot more restricted.
The base NES console and cartridge hardware has two different ROM chips: a 32KB ROM for holding the program, and an 8KB ROM for holding the graphics data. Once again, the fundamental unit of graphics data is the 8x8 tile, and it provides was two disjoint sets of 256. Background and Sprite graphics can independently pick which to use, so the options are basically "share everything" or "share nothing".
In this basic configuration, you also don't have the option like you do on the Game Boy of rewriting the sprite and background data between levels; there's only ever just the one chip. (Pretty much every game post-Super Mario Bros. had some kind of extra logic on the cartridge to let it map different parts of a larger ROM into the program or graphics space--Gradius, for instance, only needed 32KB for its program and music but would swap between two sets of graphics twice a frame, one for the level and one for the status bar.) Scrolling only part of the screen was also much harder on the NES; you were pretty much obliged to put your status window at the top or bottom of the screen because you were restricted to changing your graphics modes mid-frame. Unlike a lot of the home computers of that era like the Atari or C64, you also had some challenges knowing when to split the screen. The intended way to do it was to set a sprite at some point on the screen and then go into a tight loop seeing if that sprite had "hit the background" yet. When it did, that meant it had been drawn and it was time to change modes.
One other trick you could do, and which Zanac does, is to replace the graphics ROM with high-speed RAM chips. You could then create graphics on the fly as needed, much like you would on the Game Boy.
NES Sprite displays were pretty straightforward. Color 0 was transparent, and colors 1-3 were entries in one of the four sprite palettes, as was described. Each sprite could have its own palette, and the hardware could even automatically flip your sprite horizontally or vertically as needed, or have it render in front of or behind the background as you wished. You had 64 sprites to work with overall, and you could use them as 8x8 sprites or 8x16 sprites (created from pairs of adjacent tiles in your set of 256).
So far this isn't really too bad. Where things get ugly is the map data.
Like the Game Boy, the NES keeps a space larger than the screen to put tiles into so that you can scroll cleanly. Unlike the Game Boy, it's only larger than the screen in one dimension, so the original idea is that you would decide at game design time whether you would be scrolling horizontally or vertically and solder some wires together on the cartridge circuit board to represent this choice. (Again, later cartridges put some logic on the cartridge to decide this, from the one-dimension-at-a-time scrolling of Metroid or Kid Icarus that changes from room to room, to Dragon Warrior which hides the swap in the little pause as you changed directions on the world map, to the full 2D scrolling of Super Mario 3 and Kirby's Adventure, which accepted a bit of graphical corruption to get the power.)
Anyway. Effectively, you have two KB of memory for two screens of tiles, which gets you 32x30 8x8 tiles to build any given 256x240 screen out of. Like sprites, each gets a palette assigned to it. Unlike sprites, you can't have them flipped as they're drawn. And then, very unlike sprites, you don't have a completely free hand in assigning palettes to tiles.
This falls out of the math, basically. 32x30 tiles is 960 bytes. That leaves only 64 bytes for the palette information, and with four palettes we need two bits for each palette. This works out to each byte of color data for the background corresponding to four 16x16 regions on the map. These are arranged as squares, so this means you can divide your map up three ways and have them all make sense:
The Gameboy came later and in some ways is more capable than the NES; we only have four colors to work with and we can use them all at the same time, of course. However, it also has its own palettes as well so you can do things like my night-to-day transition without needing two copies of your graphics. You can even make some of the four colors overlap if you wanted details to gradually emerge, or to do a fade to black or white.
The fundamental unit of graphics on the Game Boy is the 8x8 tile, and you had 384 of them to work with: 128 reserved for background, 128 reserved for sprites, and 128 shared between both. This lived in a chunk of RAM that could be copied to out of the cartridge ROM as needed. There were two map areas into which you could place background tiles, each noticably larger than the whole screen, and the hardware let you set it up to display two parts at once; the main background, and then a separate chunk (bound to an edge) that covered things like status windows. That meant that you could have a fixed status window on the bottom or the right of your screen and then have an omni-directional scrolling window over the main map, all without having to do more than just asking the chip to arrange the screen that way.
But that's 1989 tech. The NES was designed in 1983, and the idea of what videogames were even for was a lot more restricted.
The base NES console and cartridge hardware has two different ROM chips: a 32KB ROM for holding the program, and an 8KB ROM for holding the graphics data. Once again, the fundamental unit of graphics data is the 8x8 tile, and it provides was two disjoint sets of 256. Background and Sprite graphics can independently pick which to use, so the options are basically "share everything" or "share nothing".
In this basic configuration, you also don't have the option like you do on the Game Boy of rewriting the sprite and background data between levels; there's only ever just the one chip. (Pretty much every game post-Super Mario Bros. had some kind of extra logic on the cartridge to let it map different parts of a larger ROM into the program or graphics space--Gradius, for instance, only needed 32KB for its program and music but would swap between two sets of graphics twice a frame, one for the level and one for the status bar.) Scrolling only part of the screen was also much harder on the NES; you were pretty much obliged to put your status window at the top or bottom of the screen because you were restricted to changing your graphics modes mid-frame. Unlike a lot of the home computers of that era like the Atari or C64, you also had some challenges knowing when to split the screen. The intended way to do it was to set a sprite at some point on the screen and then go into a tight loop seeing if that sprite had "hit the background" yet. When it did, that meant it had been drawn and it was time to change modes.
One other trick you could do, and which Zanac does, is to replace the graphics ROM with high-speed RAM chips. You could then create graphics on the fly as needed, much like you would on the Game Boy.
NES Sprite displays were pretty straightforward. Color 0 was transparent, and colors 1-3 were entries in one of the four sprite palettes, as was described. Each sprite could have its own palette, and the hardware could even automatically flip your sprite horizontally or vertically as needed, or have it render in front of or behind the background as you wished. You had 64 sprites to work with overall, and you could use them as 8x8 sprites or 8x16 sprites (created from pairs of adjacent tiles in your set of 256).
So far this isn't really too bad. Where things get ugly is the map data.
Like the Game Boy, the NES keeps a space larger than the screen to put tiles into so that you can scroll cleanly. Unlike the Game Boy, it's only larger than the screen in one dimension, so the original idea is that you would decide at game design time whether you would be scrolling horizontally or vertically and solder some wires together on the cartridge circuit board to represent this choice. (Again, later cartridges put some logic on the cartridge to decide this, from the one-dimension-at-a-time scrolling of Metroid or Kid Icarus that changes from room to room, to Dragon Warrior which hides the swap in the little pause as you changed directions on the world map, to the full 2D scrolling of Super Mario 3 and Kirby's Adventure, which accepted a bit of graphical corruption to get the power.)
Anyway. Effectively, you have two KB of memory for two screens of tiles, which gets you 32x30 8x8 tiles to build any given 256x240 screen out of. Like sprites, each gets a palette assigned to it. Unlike sprites, you can't have them flipped as they're drawn. And then, very unlike sprites, you don't have a completely free hand in assigning palettes to tiles.
This falls out of the math, basically. 32x30 tiles is 960 bytes. That leaves only 64 bytes for the palette information, and with four palettes we need two bits for each palette. This works out to each byte of color data for the background corresponding to four 16x16 regions on the map. These are arranged as squares, so this means you can divide your map up three ways and have them all make sense:
- 32x30 8x8 tiles where you have some restrictions on colors
- 16x15 16x16 tiles where you can give each tile its own palette assignment, but where generating the color tables requires a little work at run time (this seems like the most common approach)
- 8x7.5 32x32 tiles where copying color information is as easy as copying tiles into the map
A DESPERATE STRUGGLE IN THE DEVASTATION OF THE GRIM FUTURE YEAR 2020!
With civilization on the brink, choking under an endless cloud of smoke as a plague ravages the world, the stakes are survivat itself and there's no strategy too underhanded.
Only one can truly prevail in the ultimate Biome-In-Ruins Battle!
ARE YOU B.I.R.B. ENOUGH TO SURVIVE?! FIND OUT IN 1985'S HOTTEST NEW RELEASE!! by which we mostly mean we're selling these things out of the back of a truck
========
The US publication rights for the minor Japanese platformer "Forest Royalty Legend ~ Good Morning, Bird Prince!" wound up being bundled into an unrelated property licensing deal. They tried to make the best of it, but most 21st-century retrospectives agree that their attempt to make the title more marketable to the perceived main US video game audience was misguided and ultimately self-defeating.
With civilization on the brink, choking under an endless cloud of smoke as a plague ravages the world, the stakes are survivat itself and there's no strategy too underhanded.
Only one can truly prevail in the ultimate Biome-In-Ruins Battle!
ARE YOU B.I.R.B. ENOUGH TO SURVIVE?! FIND OUT IN 1985'S HOTTEST NEW RELEASE!! by which we mostly mean we're selling these things out of the back of a truck
========
The US publication rights for the minor Japanese platformer "Forest Royalty Legend ~ Good Morning, Bird Prince!" wound up being bundled into an unrelated property licensing deal. They tried to make the best of it, but most 21st-century retrospectives agree that their attempt to make the title more marketable to the perceived main US video game audience was misguided and ultimately self-defeating.
Wait, hold the phone!
There's something else coming!
It's... it's...!
...It cannot be!
FINAL EMBLEM
The crossover nobody saw coming!
IntSys originally planned to take FE:Gaiden in a far different direction, planning to ride the standard JRPG bandwagon, but the reception of FE 1 was more than enough to convince them to maybe be just a bit different.
--
Specifically mimicking Final Fantasy 1's upgraded class in-combat sprites, there's only three different sprites in there for just the walking animation, (1 more than the source material,) and 9 different sprites total in the whole animation. I did go my own way a bit with this to make it only merely reminiscent of FF1.
I'll be honest, a few frames remind me of a Terraria sprite, but that makes sense if you know the backstory there.
But hold on, 4 colors? No way!
Well, it's actually just 3 with transparency. The thing is, like many of the nifty hacks NES games pulled, early Final Fantasy had it's own in making the ground area around where these sprites fought a pure black. That way, you can just use the transparency to get black coloration/highlights while also having a more colorful sprite.
Not as nifty as Gauntlet actually using environment tiles for it's enemies so it could handle the metric ton of them it has on the screen at one time, but still pretty neat.
(Yeah, I know this is disqualified given that 8px width was the requirement and this is sitting at 16px width, but I just kinda wanted to mimic FF1. I think it came out well, though.)
There's something else coming!
It's... it's...!
...It cannot be!
FINAL EMBLEM
The crossover nobody saw coming!
IntSys originally planned to take FE:Gaiden in a far different direction, planning to ride the standard JRPG bandwagon, but the reception of FE 1 was more than enough to convince them to maybe be just a bit different.
--
Specifically mimicking Final Fantasy 1's upgraded class in-combat sprites, there's only three different sprites in there for just the walking animation, (1 more than the source material,) and 9 different sprites total in the whole animation. I did go my own way a bit with this to make it only merely reminiscent of FF1.
I'll be honest, a few frames remind me of a Terraria sprite, but that makes sense if you know the backstory there.
But hold on, 4 colors? No way!
Well, it's actually just 3 with transparency. The thing is, like many of the nifty hacks NES games pulled, early Final Fantasy had it's own in making the ground area around where these sprites fought a pure black. That way, you can just use the transparency to get black coloration/highlights while also having a more colorful sprite.
Not as nifty as Gauntlet actually using environment tiles for it's enemies so it could handle the metric ton of them it has on the screen at one time, but still pretty neat.
(Yeah, I know this is disqualified given that 8px width was the requirement and this is sitting at 16px width, but I just kinda wanted to mimic FF1. I think it came out well, though.)
-
- Site Admin
Ehehehe, both good submissions, and yes, despite being disqualified, that is a solid entry with knowledge of the tricks people pulled. Still, it be spooktober, so let's have a nice, fitting challenge.
Spooktober Challenge!
So, this will be the first one where I am not setting a palette restriction. While I do very much hold to "Learn through limits", sometimes, you just gotta cut loose and let people try things for the hell of trying things.
With that said, I want you to make spooooky items that would be in a game... Maybe it's some bones. Maybe it's an eldritch chest. Maybe some small part of a long dead god. Minimum of 4, and the size requirement is 16px for each (16x16), but if inspiration strikes, and you want to make more? COOL!
Oh, one other requirement, because this is generally required with a good spritesheet anyway: Pick a single background colour (preferably the one you imagine the item box background would be.) And give them space, I'd say 3 pixels between each sprite is a good idea.
So, get spooky, pixel-buds!
Spooktober Challenge!
So, this will be the first one where I am not setting a palette restriction. While I do very much hold to "Learn through limits", sometimes, you just gotta cut loose and let people try things for the hell of trying things.
With that said, I want you to make spooooky items that would be in a game... Maybe it's some bones. Maybe it's an eldritch chest. Maybe some small part of a long dead god. Minimum of 4, and the size requirement is 16px for each (16x16), but if inspiration strikes, and you want to make more? COOL!
Oh, one other requirement, because this is generally required with a good spritesheet anyway: Pick a single background colour (preferably the one you imagine the item box background would be.) And give them space, I'd say 3 pixels between each sprite is a good idea.
So, get spooky, pixel-buds!
-
- Site Admin
Ah well, spooktober's a quiet time anyway, so, because the thread would feel unspooky without, here's my collection of items.
Bones, the perfect gift for the necromancer in your life!
Tired of adventurers in your spooky castle? Cursed chests are the answer!
Witch's hat, always have a spare in case one blows away!
Mandragora. Thank god this one finally shut the hell up, it was killing your ears.
Sacrifical dagger, but on the cheap. Perhaps... You should have gone to a better cultist supply shop?
Glass of "wine." Stick a bottle of actual wine nearby, and bam, you've got an easy thralling date!
Frogbomination. We thought we could create a frog nugget with magic. We were so very, very wrong. Still squeals adorably though!
Bones, the perfect gift for the necromancer in your life!
Tired of adventurers in your spooky castle? Cursed chests are the answer!
Witch's hat, always have a spare in case one blows away!
Mandragora. Thank god this one finally shut the hell up, it was killing your ears.
Sacrifical dagger, but on the cheap. Perhaps... You should have gone to a better cultist supply shop?
Glass of "wine." Stick a bottle of actual wine nearby, and bam, you've got an easy thralling date!
Frogbomination. We thought we could create a frog nugget with magic. We were so very, very wrong. Still squeals adorably though!
-
- Site Admin
November Challenge: Express Yourself!
Okay, well, although last month was a quiet month, we're going to do a theme challenge this month. No limits, although I would highly recommend new folks try <128px and restrict their colour palette (believe me, you'll thank me later for that advice.)
And the theme? Expression. That could be something like a facial expression, someone expressing themselves (and there's lots of ways to do that), a situation in which body language plays a big part... Go hog wild, folks!
Okay, well, although last month was a quiet month, we're going to do a theme challenge this month. No limits, although I would highly recommend new folks try <128px and restrict their colour palette (believe me, you'll thank me later for that advice.)
And the theme? Expression. That could be something like a facial expression, someone expressing themselves (and there's lots of ways to do that), a situation in which body language plays a big part... Go hog wild, folks!
We don't have enough memory to store a real "level", but this screen has been cleared and that means it is time to do the happy dance.
Keen-eyed viewers will notice some continuity errors in Grassland Greg's clothing; this is due to the console being, technically, monochrome, so the sprite engine selects a new color from its substantial palette for the sprite each scanline.
Keen-eyed viewers will notice some continuity errors in Grassland Greg's clothing; this is due to the console being, technically, monochrome, so the sprite engine selects a new color from its substantial palette for the sprite each scanline.