Pixelation
Critique => Pixel Art => Topic started by: Arne on September 14, 2010, 07:23:38 pm
-
I decided to take a break from what I'm supposed to be doing and just play around a bit -> Reinterpreting the SMB 1 sprites with a partially lost black line style, using a 4-5 color restriction. I didn't think much about palette limits or anything like that.
(http://androidarts.com/misc/smb_edit_3.png)
Bit if a rush work. I guess awesomeface Starman turned out the best.
Small lessons rubbed in: The importance of simplifying any sort of random noise or squigglyness into a simple line, curve, circle, definite structure (or remove completely). Extra colors can actually reduce readability. Roadsigns have few colors, after all.
Lessons not learned: ?
-
Very nice style and it should work on the NES as well, some things would perhaps be simplyfied colourwise to get to the 4 sprite palette limits. But other than that I really have no crits.
-
lovely in overall. The only thing I would stand against is the use of black on the distant "hills". They mess up with e.g. goombas feet.
-
Agreed about trees. Maybe. At any rate I'm cautious of using black in the background since I like it low contrast/fogged. I notice now that I did have a darker but not black color available. It's used on the underworld tiles.
Now it looks a bit wimpy. A hue shift difference might improve the situation.
The fish lost a bit too many of its lines I think, so I added a few.
I also wanted to lose some on the top of the Goomba head. Not sure how that works. Looks like I was too aggressive. It's easier to subtly lose line on the curved bits.
(http://androidarts.com/misc/smb_edit_4.png)
Well, the animation sort of works, but it looks kind of strange.
(http://androidarts.com/misc/goomba.gif)
Should Mario have a mullet? He's a bit blocky there. His legs/feet are kind of rectangular, and the lack of lines around the hand bothers me but as soon as I tried to add some he looked 'cut-out'.
-
I think the animation could do better with either a bob or head rotation... or both.
(http://www.mariowiki.com/images/b/bd/Nonstopper_NSMB.gif)
Given your very stylistic choice here, I think something very exaggerated would fit these sprites better.
-
Yeah, perhaps.
Wasted some more time doing enemies from... I'll let you guess.
(http://androidarts.com/misc/smb_edit_6.gif)
-
Lovely! <3 Two things.
I messed with the goomba a bit, the animation had his back leg poking in either direction and i was wondering if something where the feet were planted would be better. It loses the wobbly goodness and just feels static, but I wonder if there's something in there that you might find useful.
(http://lolipopsicle.com/uploader/uploads/goomba.gif)
The second thing is, I thought for a long while that the tree trunk was some sort of naked man, until I read that there was supposed to be a tree. I mean, the little dudes got a body with arms and feet, and a head with eyes and hair and all! o u o
-
Psh these versions are so much better than their originals. Oozing with character even at that res and limitations, so nice. Ha, you even got the red crab in there from the old smash bros! That a Donkey Kong crocodile chomper thingy in top right? Hey you need a chomp-chain.
-
Wow, this is a really nice idea and an awesome attempt. Something about some of the black outlines seem to jar though. It's like the black is too harsh but I don't see a way around it either. The darker ramps were already used in SMB1 so that defeats the object and goes without saying (but I've mentioned anyway)...
I wonder if looking at some Gimmick! screens might be useful, as the Sunsoft artists used less black there and got a similar result.
http://www.vgmuseum.com/pics5/gimmick.html
It's the best example of similarly stylistic pixel art on the NES/Famicom in my opinion, so I hope it's a relevant suggestion. The clouds in particular are top-tier.
(http://i261.photobucket.com/albums/ii47/L___E___T/GimmickJ07.gif)
-
Heberekeand Gimmick are both supercute. I don't really mind the black much. I've got a bit of a dislike for colored lines around sprites with few colors.
(http://androidarts.com/smb/smb_edit_8.gif)
SMB page (http://androidarts.com/smb/SMB.htm) - I don't know where this project is heading. I just wanted to draw some stuff. Animation is later concern. Usually it becomes really clear when running ingame which animations work and not. I actually programmed a primitive platforming engine some time ago, so I'm thinking I could put these gfx in.
-
God damn your mushroom kingdom is adorable :3
-
cool :)
got a programmer? feel like animating these?
nice spin on the graphics. got any spins on the game play?
-
They get more and more lovely!
However, the animation on the goomba (http://androidarts.com/misc/goomba.gif) stresses the fact that broken outlines looks weird, especially when animation make them open/close. Shadows would work. Full outline would work (possibly using a darker, non-black colour for sub-pixel effects), although it's not the direction you've chosen, obviously.
-
cool :)
got a programmer? feel like animating these?
nice spin on the graphics. got any spins on the game play?
I can answer this for you: take a look at http://androidarts.com/smb/SMB.htm
(:
-
That goomba selout really bugs me, yeah. Thought it was a very odd choice. That man-eating flower's green pipe is strangely drawn.
3 different HP states/sizes of Mario? That's an interesting idea; why not.
-
On the bottom blue ground tile, what do the single pixels on the top of that tile signify? Nearly all the single pixels I've spotted (mario's hat, top of bushes, eye of the blue bird) are hurting much more than they are adding.
-
Actually looking at the blue blocks, they look odd. It looks like the thin lines are jutting out diagonally from the bottom of the block. And I agree with Helm about the single pixels. They indeed do not add much in most places.
-
I was gonna do a proper blue block, but thought I'd try and see what happened if I just changed the palette. This unfortunately resulted in some meaningless pixels popping out. I was wondering if someone was going to notice eventually (several have). I need to do a proper one.
The Goomba head shave only bothers me where it's strictly horizontal (like I said before, I think it works better on curved lines). Yeah, when it animates it becomes really jarring.
The unorthodox pipe is a strange homage to an image I had in my head of the Giana Sisters pipes.
http://www.mobygames.com/game/c64/great-giana-sisters/screenshots/gameShotId,109621/
But it was also a way to break up the gradient of the pipe curvature. Large clean gradients are tricky to do with a limited palette. I wanted to leave the pipe open at the top, so I omitted a line, but it looks kind of odd. Looks too flat with a line though, and a line closes the pipe. Also, the ground doesn't have top lines either.
No one has commented on the white gloves yet. I thought those were risky. Highlights on black spherical surfaces was a bit of a questionmark too. The crab is such a mess. Blackface Bullet Bill is a bit of a deviation (could be Missile Marty?), and the lack of black lines on the fins bother me, but I couldn't solve it. Blooper tentacles are a mess.
I can't say that the bush pixels bothers me. I think they are needed to suggest material/texture. Otherwise the bushes might look like plastic or lollipops.
(http://androidarts.com/smb/smb_edit_8.gif)->(http://androidarts.com/smb/smb_edit_9.gif)
Changes: Mario hat pixel, Goombas (their closed line bother me a bit now,when compared to Mario's now even cleaner hat for example), Fish (using a two-tone in the mouth, inconsistent?), Bird nostril gone. Far eye doesn't bother me. Should it?
New blue / dark teal blocks. They're not meant to stack vertically, as there's a drop shadow at the top. I just forgot to erase those at the bottom. Ran into some pillow shading/banding problems that I didn't fully fix because I got sloppy.
-
On mario's cap, maybe you should have a red pixel instead of directly replacing the black one with an orange one?
-
Goombas with full black outline sing true to me because it's an enemy you often have to do pixel-perfect jumps on top of, it's good to be clear at all times where their 'landing area' so to speak is.
No I don't think the far eye on the bird is hurting it, because it's mirrored by near eye.
The speculars on black surfaces are fine, I tried making them T tetromino clusters with blue pixels that you already have on the shell sprites, but it looks more visible than it should.
The treetop pixels issue could be mitigated easily by the inclusion of a second darkest shade that isn't pure black, I think. Do the limitations allow?
I think the pipes look great, personally. I tried a different thing here
(http://www.locustleaves.com/wrongpipe.png)
But it sucks. Too rendered, too much of a loss of the color identity. Are you sure you don't have a second green somewhere in that palette? Heh.
That would fit a Sunsoft Batman game at least!
-
Arne, that is indeed one neat Mushroom kingdom ya got there, I think I recognize everybody but the dudes of the up-left corner (up-right is Mario Bros 1 screen game) and that guy who shoots lightning.
Now, for crits....first of all I want to reccomend to all of you if you want to see the best Nintendo has done with mario 8 bit, to check out the game and watch gallery Gameboy Color games, they're adorable.
http://www.spriters-resource.com/gameboy/gnwgal3/index.html
http://www.spriters-resource.com/gameboy/gnwgal2/index.html
http://www.spriters-resource.com/gameboy/gnwgal/index.html
Second, if you're gonna break the outlines make it look like they're the darkest shade, try to make it look as a lighting effect so that it isnt so awkward, KOF does this without any buffer shades and without any awkwardness if you want to check that out.
(http://i22.photobucket.com/albums/b340/baybaybom/goomba.gif)
Here's an edit with cut black outlines as if they were an effect of lighting, also I removed the outlines from the stem to better diferentiate the shoes, and I made him tiptioe sideways like in Yoshi's Island walk...aside from the DK.Jr game in G&W gallery that was the goomba's best moment
EDIT: quirkier goomba (http://i22.photobucket.com/albums/b340/baybaybom/goomba-1.gif)
(http://i22.photobucket.com/albums/b340/baybaybom/goomba-2.gif) fagfslflasdfiofsho =O it's just fun to do something like this...I've been animating some really complicated stuff lately O_O
-
Wow, Helm's genius is always spot on. I'm not being sarcastic, no. I took another look at the black outlines and changed my tune completely, I also think the fully lined Goomba looks better.
Question on the teal blocks though - how will they tile in the underground stages? Or are they gone?
Lastly, I saw your notes on the gameplay changes - I think these are massively significant, it would be great to see the start of some of these and how they fit in with/affect the world as a whole. Especially interested to see dust effects, vehicle smoke, flying animations et al. Everything as a whole so far reminds me of the 'bob n float' style of the new SMB games on DS and Wii to some extent.
# Goomba's shoe - Walk on spikes. A vehicle? The SML vehicles were cute and fun too.
# Stone statue - I dunno, this one wasn't very fun to use. Maybe it could be used to sink to the bottom of a very salty (floaty) lake?
- The tanooki suit WAS the most fun! It's invincible, so you can jump over a thwomp, turn it on and kill it by stomping as you fall! This works for fireballs, ghosts and all sorts!
# Air jump (aka double jump). Wing-boots?
# Wall grab/slide
# Wall jump
- Smash Bros style?
Sorry if I'm digressing too much from the pixels and towards gameplay, but if you can agree that the pixels shout communicate all this anyway pretty much, then I would hope that it remains relevant to discussion :)
-
This is very nice -- bursting at the seams with personality!
A few quick nitpicks:
- It might look nice if the bottom-most floor blocks and the blue blocks under them tiled better. That might not stay true to the source, but this is about improvement, right? There are plenty of blocks that don't tile (the "staircase" and some of the floating platforms) to maintain the Mario spirit.
-On the star icon, I would remove the bottom part of the mouth where it bleeds into the "leg" on our right. This would keep the open mouth without interfering with the clarity of the star shape.
Keep up the good work!
-
love the style, goombas and airplanes are my favorite sprites. i agree with what someone said earlier though, that tree looks just like a guy with a bush on top of his head.
-
I just read your page about the changes....you say the statue wasnt fun? I take it you never used it while in midair, it was like a Thwomper mario suit! it's almost as powerful as the eskimo mario...I think it even out-stomped the thowmps I would run out of time because I got too distracted stomping stuff all the time :p :crazy:
-
I have a dark green which I use on the pipe, but I didn't use it on the trees even though I could. I think my rationalization was to keep things flat if possible. The pipe really begs for some roundness though, so I broke two rules, highlight and slight dither and shadow. Uh, three.
I tried to keep it flat and undithered as far as I could though. And some of the shells have speculars so I didn't really break that rule too much.
I tried softening the speculars, but it looked like... the star skies I tried to pixel on my Amiga back in the day.
Top left guys are Snapjaw and a plain bird from DK.Jr. Yellow bot is from the Nintendo Power comic based on SML.
I played a lot of Game & Watch games as a kid. It's why I included the Snapjaws. The arcade and NES version of DK.Jr. is pretty cute too.
http://www.spriters-resource.com/gameboy/gnwgal3/sheet/8965
I wasn't too impressed by the Game & Watch ports to be honest. And the Snapjaws in Mario vs DK looked very bad.
http://www.mariowiki.com/Snapjaw
I thought about punching up the http://en.wikipedia.org/wiki/Chiaroscuro effect (make some of the lines into more defined shadows), but decided against it (I don't want a Mignola look). I'm doing it mildly here and there though.
I still can't see the tree-man :o
I don't know how I used the statue power. I guess it could be fun to use if Mario kept is momentum. Maybe turned into a stone ball which could crash blocks, enemies etc. Like a wrecking ball.
Animations: I was thinking of giving each character the same set of animations, whether they use them or not. They can be blank frames, copied, or whatever. It's easier layout the sheets and code stuff this way. Having the engine alternating two idle frames for example is good if you feel like adding a simple animation later.
Stand idle 2
Duck idle 2
Walk 4
Run 4
Slide 2 (turn/skid when attempting to move in opposite direction of movement)
Duck slide 2
Jump up 2
Hit top of head/hand 1 ? (brief overriding strain frame)
Fall down 2
Hard landing 1 ? (brief overriding strain frame)
Throw 2
Float idle 2
Swim 4
Wall idle/hug 2
Wall climb 4
Wall kickoff 1 ? (not sure if a transition to the regular jump frame is needed)
Take hit 2 (pain / flash, Megaman style ? Alternatively, Mario could emit shock particle without being interrupted.)
Die 2
Crushed 2
(flipped frames excluded, engine does that)
(http://androidarts.com/smb/editor.png)
Ingame editor with a BG and FG layer. Mario is the little dots. Edit: Oh, it's 16px based for now. My 8px alignments are artificial. This is a quick test with just 16+16 block types.
-
the top portion of the trunk is his head, the bottom portion is his body. the black cluster at the top of the top portion is his hair, the black line in the center is his eye. the two lines in the lower portion separate his arms from his torso, and the black pixel at the bottom separates his feet.
(http://i57.photobucket.com/albums/g209/phototekcub/treedude.gif)
I can't see anything else now!
-
Arne, just to add on something - the Tanuki suit is not a statue power. What it is a mythical raccoon-dog native to Japan. To the Japanese these were seen to have powers of transformation and magic, including disguise. The suit is a magical raccoon-dog and has the added power of transforming into a statue.
If you took the statue thing too literally, it would be a digression and lose the character of the suit. A better idea would be to elaborate on the transformations I'd say.
Watch Pom-Poko and you'll see what I mean, just look on youtube or read below:
http://en.wikipedia.org/wiki/Pom_Poko
To add something more on-topic (to pixels), I can't help thinking that the smaller brick blocks and corners need a change of highlight. The current highlighted layer looks too seperated imo, plus I really think the little bricks could benefit from a pixel or two of highlight on each.
What do you think? Oh, just another note - the Eskimo suit someone referred to is a Hammer Bros. suit, it's just only found on the ice level is all. It would be great to see your ideas/approaches on new suits - or using older suits from other SMB games, like the cape or bunny ears etc. You've got the vehicles so that could be really nice I reckon :)
-
(http://i22.photobucket.com/albums/b340/baybaybom/goomba-2.gif) fagfslflasdfiofsho =O it's just fun to do something like this...I've been animating some really complicated stuff lately O_O
I love that "flappy feet feel". Very inspiring ^_^
-
I think I can actually unsee that tree man.
I spent the day programming. Now blocks will bump (in any of 4 directions). I solved it by not doing a regular map array. Instead my map array links to instances of blocks. It requires a bit more memory (or not, since empty map cells are just NULL), but it also means that I can give blocks lots of properties and do cool OOP stuff. I temporarily put them in a bump list when bumped, so they animate for a while.
I'm thinking of overlaying a screen sized camera-locking array over the map, so I can restrict the scroll like in Zelda, Metroid or the newer Metroid games where you can find a secret which unlocks the camera so you can see what's below your feet for example. Centering the camera on the player often shows lots of ground or stuff below the ground which perhaps is irrelevant.
http://www.hardcoregaming101.net/hudsonmario/hudsonmario.htm
I can see some DK and MB enemies :O
-
Could you give some positive comments on why you chose Blitzmax? I know thats a little vague.
The website has lots of information but just some perspective would be educational.
Thanks for the link jad.
-
BMX is nice and scalable for me. Perhaps it can be said to be a mix of C++ and regular BASIC. It does not have any 'game making' features with editors or such, so you'll have to program engines from scratch. At least that's what I do. It uses open GL for gfx, so there are a few things to think about there. Pixel gfx is basically textures and stuff handled by the GPU. Fast. Programming palette swaps and pixel manipulation is a bit trickier.
I grew up with C64 Basic, Amiga Basic, Amos, etc. Seemed natural to use BlitzBasic after that. I've tried a lot of other languages, but I come back to BMX. It's easy to get results early, and you can still do complex stuff thanks to the OOP features (Classes, inheritence, linked lists, function pointers, etc.)
I just spent some time struggling with jumps. Up until now my lazy implementation was to just make the actor jump if a button was held and there was ground contact. However, it looks bouncy. Normally in games I think you have to release the button and land to recharge the jump. However, after having implemented that I missed a lot of precision jumps because I hit the button just a little too early while in the air. I don't think I want to program a look-ahead system which checks if the actor is about to land on a block or not. It could be useful for implementing a preparing-to-land animation frame though.
I think I'll do this instead: After the actor lands, it will spend a brief moment landing (and probably sliding). I could actually check the hardness of the landing here and use different animations, bending the knees more or whatever. The brief time spent in this state will negate the unrealistic instant bunny jumping feel, while allowing players to make single block jumps with less frustration.
That's the theory anyways.
-
Uploaded a test build. Windows.
http://androidarts.com/smb/
Quick placeholder stick-man included.
Edit: These friction, gravity and movement speeds are just for showing off the character animations, sliding, changing between states etc. Deliberately floaty and slidey. Next build I might put them in a text file.
-
awesome :)
Nice editor
Thanks for the insight. I've returned to school pursuing an RTIS degree. Perhaps in a year or so I'll check out Blitz.
I really appreciate you posting the programming progress as well as the art. The elaboration on your challenges and solutions is also educational. :y:
-
Sorry, I have no critics.
Just wanted to point out that you're an inspiration.
Your sites are very educational and the way you remake old tiltes with new ideas and concept art... I love it! :blind:
Okay, go on.. and keep it up.
-
Took the bull by the horns and started adding roughs to a 256+256 tile sheet. Working on a new editor which will let me edit the maps easier. It's a pain to write editors though, so I'm thinking I should leave the editor simple and enable importing/exporting images instead. This way I can edit the map in PS as an image. Lasso move, copy large chunks, etc. I might either do it in 24 bit mode, but then I have to come up with a way to generate good colors. I could average the tile colors and make sure that all are unique. Or I could make a random palette, or I could let the user (me) make one. I could also work in indexed mode, in which case the palette doesn't matter. I wrote a BMP exporter for Cortex Command, but I don't know if I can write one which consistently loads BMP's saved from PS or so.
Another option is to use the Photoshop RAW format. It can be set up to be very straight forward. You need to know the dimensions and amount of channels (e.g. R,G,B or Index) when opening the RAW file though. Then any palette can be applied afterwards. Edit: worked!
(http://androidarts.com/smb/AllTiles.gif)
-
An wild insight appeared. Whenever I do terrain tiles I kind of run off doing wild structural variations. However, somehow a tiled look with a few well made blocks always looks better. Maybe the eye likes structure.
So, this time I started doing the usual varied rocky hill thing. No matter what colors I dressed it up in, it just looked out of place. Mario needs structure, blockyness, a rigidity. But I didn't want to use the same tile for entire mountains.
So, I thought, what if I keep the structure of the original block design, but treat it as if it was a mass produced thing which has gotten exposed to wear and tear?
To do this effectively, I needed one more color so I could go a little quiet where I needed to. I nearly went for a dark to, but it killed the simple graphical feel. I hope that the yellow-orange which I added don't.
Anyways, I started playing up and down detail strength, pushing in and out chunks.
I think it works. The horizontal highlight on the top gets more emphasis, and the grit 'underground' won't distract as much or flicker/distract when scrolling horizontally.
(http://androidarts.com/smb/tile_test.gif)
The bushes look mighty simple now though. Maybe I should toss in that dark green Helm(?) suggested. But I don't want to slip down a slope and add aliasing or elaborate softening shadows to stuff.
Thinking of punching my yellow-orange up a bit in brightness (or brown down?).
-
Not sure if I should have background rocks like this or not. I'm tempted to Fade the BG colors into the sky a bit more, anyways. Probably turn them more blue so there's no question that they belong to the sky. Bit of a mess now, too with the noisy gritty BG blocks I threw together.
(http://androidarts.com/smb/background_play.png)
Edit:
(http://androidarts.com/smb/pushback.png)
-
lighter blue doesn't work very well for near-bg items such as lanterns, pipes and caves. I could work for the statues (although hinting them as fairly distant) and is definitely a must for hills in the current setup.
Also, breakable bricks look fairly flat compared to everything else you have touched. Maybe SMB3 could be inspirational on this.
-
This is starting to look really interesting, I hope you keep at it :)
A nitpick I am having is that the darker greeny-blue on the pipes is too close to the black and looks not very nice on the sides where you are basically mainly repeating the outline of the pipe.
-
Whoa, forum layout changed when I clicked reply. A style update, I'm guessing. It's all mystery meat, and also ineffective since it doesn't make much use of colors, just silhouettes.
The flat brickwalls doesn't bother me. actually. I think highlights would be damaging, even.
The darker BG gfx confused me. I didn't know where to stand and what to dodge. I've thought a little about having two fog distances, but I dunno. I'll know later once once the environments are coming together in the game.
The pipes are a bit sloppy. Also problematic since Mario might stand on pipes which aren't as thick as they should be (a full tile.) Might be able to cheat with that in the engine though. Or I could use thicker parts where Mario Will be able to stand, and thinner parts where the pipe is embedded in terrain. I added the 'ears' early on because I was aware of this problem.
Lightened the yellow-orange a bit.
I think the SMB 2 root fruits are great for spinkling meaningful ecology around the map.
I think once a power has been acquired, it should be permanently available. However, unlike animé, enemies can attack during transformation scenes, so Mario must be in a safe place and can't abuse transformation mid air (to throw a single hammer or whatever). Transformation could require that Mario have stood still for 3 seconds or so, then transformation takes another second or two to complete (poof cloud). During this time Mario is vulnerable.
Alternatively:
Mario transform a bit like Psycho fox, using up charges each time.
Not being normal Mario drains some kind of transformation energy meter.
(http://androidarts.com/smb/smb_edit_11.gif)
I'll scan some concept art when I get back from voting.
-
Here are some ideas for the map.
(http://androidarts.com/smb/map_concept.jpg)
-
I agree with you about organic looking wrong on mario, But I disagree about the tear. To me it works better when you stop trying to make things like they really look, and just have fun with patterns.
Dr.Slump's island
(http://www.forodefotos.com/attachments/series-anime/6224d1225824020-dr-slump-dr.slump.jpg)
http://www.youtube.com/watch?v=OLiku1IcPnM to me is a part of mushroom kingdom...it's the kinda world where a mountain smiles at you, you know? no need to make it plausible.
What I mean is, dont try to break the patterns but instead make many many kinds of patterns and makethem look really good, like these games
(http://fidgit.com/assets_c/2009/07/Fat_Princess_release-thumb-550x309-21433.jpg)
(http://www.ps3vault.com/wp-content/uploads/2009/08/Fat-Princess-1.jpg) Fat Princess
(http://www.wired.com/images_blogs/photos/uncategorized/2007/10/24/animalcrossing.jpg) Animal Crossing
(http://www.nintendolesite.com/images/dossiers/dossier_NDS___L__hiver_sera_chaud__partie_2_2__2.png) rocket slime
I know none of this is sidescroller (barely any pixelart :p)...but my point was more about the mood and aproach to detail
-
In my case I do explain the face-mountain though. I plan to make a large version of it where you can see that it's just blocks :) I'll also try to put some ecology into the game. That aside, I want it to stay inside the confines of SMB as I imagined it as a kid. It wasn't just a bunch of linear levels and simple sliding enemies, it was a whole world to explore, populated by interesting things.
I've done some photoshoppery with the map. These blocks should be 25*18 pixel screens if I've done the numbers correctly. That's 400*288.
400*300 is my fav retro rez. 320 * 256 feels a bit claustrophobic, look-ahead-wise, especially with larger faster characters. Also, it will 2x nicely on my eeePC (1024*600).
(http://androidarts.com/smb/screen_map.jpg)
28*10 screens. 700*180 blocks total. Not that large, but I''d like to keep it small and well populated to begin with. Hopefully most screens will have some meaning or feature, and won't be just filler.
Metroid 1 map was 32*32 screens (but those screens were smaller).
-
Ok, I hope you still get what I meant as an aproach to tiling. Instead of a tile and variations of it teared, as an aproach to variation...there's alot of different patterns that look really good.
that map looks great, seems ike it's smaller than average mario? makes me wonder how much screens mario3 would take if it was represented that way.
it's kinda weird but fun to think of a mario map in that metroidesque way, the overworld maps are kinda ingrained in me :p
-
Initially, I posted in this thread saying something basically like, "Oh heck yes!" but it was quickly removed by a moderator. ;D I'm posting again in this thread, though, in the hopes that I can offer some thoughts that are a bit more substantial, as well as better explain what is it about your work here that has me so enthused.
Not sure if I should have background rocks like this or not. I'm tempted to Fade the BG colors into the sky a bit more, anyways. Probably turn them more blue so there's no question that they belong to the sky. Bit of a mess now, too with the noisy gritty BG blocks I threw together.
I absolutely love the background rocks, the background pipes, and the statues. You've suddenly added a dimension to the Mario universe through the simple use of sensible world construction. Instead of blocks just floating in the air (not that you won't have plenty of that), we can now begin to imagine a structure to this world. Things seem connected to each other. We can imagine a network of pipes interconnecting different parts of the world. Dare I say it, we can even imagine something like a culture for the koopas and creatures of this strange place, seeing walls and statues all over the place. It's a small touch, conceptually, these rock and pipe backgrounds, but man, I'll tell you, when I saw that, I got such a thrill from this project. Prior to that, I hadn't thought much more about it than: Neat Mario sprites. After that, I could imagine an entire game world and a strong contribution to the whole Mario concept. I really feel like this game you're mocking up (hopefully making, for real) might have the capacity to engage the imagination in that wonderful way that games did when we were kids.
I think once a power has been acquired, it should be permanently available. However, unlike animé, enemies can attack during transformation scenes, so Mario must be in a safe place and can't abuse transformation mid air (to throw a single hammer or whatever). Transformation could require that Mario have stood still for 3 seconds or so, then transformation takes another second or two to complete (poof cloud). During this time Mario is vulnerable.
Alternatively:
Mario transform a bit like Psycho fox, using up charges each time.
Not being normal Mario drains some kind of transformation energy meter.
This is probably obvious, but you'd have to do that with great balance. I think it could be very cool. I wouldn't suggest a full-on Metroid-style Mario, as absolutely weird and fun as that might be -- but I would urge you to make the abilities difficult to acquire, after boss battles and big challenges, if the idea is to have them be permanently available.
Additional thoughts:
I really like your concept for the world map. I like how everything feels connected, and how well that ties in with your network of pipes and connected rocks backgrounds. I love the idea of employing the "warp" concept where you have that pipe that can drop Marne from Pipe Mania to the Lost City.
I really dig Mario flying the plane.
I'm sorry to be so positive. I'd be more critical, perhaps, if I had more expertise about sprite-work and pixel-art. On that front, I'm mostly here to learn, observe, take inspiration, and pipe up here and there when I think I have something to offer. In this case, I don't have much to offer except for enthusiasm. But at the same time, I am learning just by reading some of the other comments and suggestions in this thread.
-
Thanks!
Yeah, I understand what you mean about using tiles to do architecture. I'll have to be careful and avoid obstacle course level design, since I don't like that much. Some atmospheric background graphics could probably help to make a location seem less artificial even if the foreground blocks are clearly a 'gamedesigny' puzzle of some sort.
This might give a better feel for how large/small my map is. I don't know how big the SMB 1 one is. Hmm, I just noticed that I had a few pages open in tabs:
http://ian-albert.com/misc/smb.php
http://strategywiki.org/wiki/Metroid/Walkthrough
(http://androidarts.com/smb/screen_map_wip1.png)
First I was going to put warp points or something in the pipes - entry and exit. Then I got the idea that the pipes could very well be physical. If Mario enters a pipe, I could step through the segments and find the exit point easily, I think. Castles will have to warp the player to the castle area.
When working on this map I'm taking my planned scroll restrictions into account, so some areas won't be revealed unless the player enters from a certain angle or so. I've also hinted at some level design puzzles, artifacts an other stuff. Most of the map is unfinished though. I think I might have to go above 256*2 tiles eventually.
Edit: Oh, another thing. I wrote a simple tile based boulder dash type lava (http://androidarts.com/gamedev/lava.gif) routine once, so I drew a lava puzzle into my map. The routine works poorly with water since it's more fluid. Lava can get away with being chunky.
I might have to do all of the BG gfx, or most, in differently colored sets. Sky, Dark Cave / Space, and Water. Maybe I can solve it programatically though. Edit: before I forget, here's how I could do it. Store the light and shadow if the BG stuff in separate images. Each map cell gets an extra byte for BG color. Before I draw the BG images, I check the BG color, and colorize the light and shadow images on the fly (basically just a Case Select/Switch and SetColor R,G,B which I already do for many images. In BlitzMax / OpenGL, scaling, rotating, multiplying, 'screen'ing and tinting images is extremely fast. I already tint all images pure white.
Yeah, this approach is good because it also makes map editing easier. If I do choose to do water, I could flood an area with a blue water color and all drowned BG thingies would automatically adapt.
-
In my case I do explain the face-mountain though. I plan to make a large version of it where you can see that it's just blocks Smiley I'll also try to put some ecology into the game.
Whereas this is fascinating and I'm looking forward to see what a SMB with more verisimilitude could achieve, I have to say I find it psychologically worrying that you seek to inject positivist linearity in a game that most took as childlike few-rules fantasy. I don't necessarily think you're doing anything wrong, in fact I enjoy reading your game analysis stuff as much (or more!) as most users. I just worry about you, Arne. If a smile needs to be explained with architecture, you know... :)
-
Edit: Oh, another thing. I wrote a simple tile based boulder dash type lava (http://androidarts.com/gamedev/lava.gif) routine once, so I drew a lava puzzle into my map. The routine works poorly with water since it's more fluid. Lava can get away with being chunky.
I can't say for sure without knowing the algorithm, but I'm pretty sure it should be quite easy to program more "watery" water physics.
I haven't tested it, but I think this should set you up:
Pseudo Code:
for (x = each row from bottom to top) //go over the entire grid. start at the bottom so all particles can fall in the same iteration and not block each other
for (y = each column from left to right)
if (there is a water particle here) //try and see if there's a place below to move it to
i<-0
while (searching)
if (can search left)
if ( there is a free spot in [x-i,y-1] )
move the current water particle there
stop searching
if ( there is an obstacle in [x-i,y] ) //if there's some obstruction that should prevent this particle from going further left or right
can search left <- false
if (can search right)
the same but with x+i
i<-i+1
if (cant search left and cant search right)
searching<-false
-
Haha, well, I'm not the first one to try and 'explain' SMB. However, when I was a kid I never saw the game as an abstract "oh it's just a game" game. My imagination always fleshed out the worlds that I visited in games.
I'll try and port that pseudocode to see what happens. As I understand it the blocks will pretty much teleport to the first lower position found sideways, rather than forming a pile like in BD or scatter out randomly like my lava. I see a problem with a 50% filled reservoir though. And, water is more likely to even out in U tunnels, so that might look a bit off. Not really a big problem though.
I believe that just having a primitive fun feature in there at all is more important than polishing it to the point of very diminishing returns. Having destructible terrain even at just a block based level in SMB or say, minecraft, is worth a lot. It might even be better to keep it simple in some cases.
With my lava I planned to explain the chunkyness in a very SMB way. I'd use an onscreen on the fly effect to soften the corners of the lava (finding islands and protuders). Then I could draw cute little eyes on some, like the platform/toothpaste ghost platforms in SMB3, or was it SMW? I drew that effect on one of the earlier concept art sheets.
Here are some doodles from the night. I spent some time cleaning them up in PS.
(http://androidarts.com/smb/remains.jpg)
-
Well, that took a bit longer than expected. I used an RLE optimization. It could use some more work, but it already brings down the calculations to well under a millisec for my 700*180 map, and that's only if the water is disrupted. On top of this, I actually make 10 simulations per frame, not once per game tick, like in say, Boulder Dash. This way my water will flow nicely and quickly though corridors and such. Other techniques have the disadvantage of teleporting the water so you can't see how it flowed, or move the water too slow, making it seem like sand or lava.
Another thing that I do is scattering the water. Some algorithms will produce nasty vertical shafts if there's a leak. This happens when falling down is always prioritized. It will cause an 'edge of the world' wall of water. I occasionally jitter the edges a little so the water forms nice splashy piles.
(http://androidarts.com/smb/rle_water.png)
RLE bottom-top optimization plotted for clarity/debugging. It took some head scratching to get it to work. Static water cells are removed from the simulation until disturbed (or their neighbors are).
Idea mentioned in earlier post. This will be a visual effect and nothing that's part of the water simulation. I can look at neighbors and perhaps figure out a suitable water tile. I'm worried that since the water jitters around a lot, it will look kind of crappy. Also, it will probably be hard to figure out if the waves should be toned up or down. I might be able to build a table, like the HQ3x algorithm does.
(http://androidarts.com/smb/soften.jpg)
Edit: I'm retarded! My millisec counter code was wrong and when I corrected it the MS count jumped up 20x! The sim still runs under a 18ms (which is a frame), so I didn't see this. Luckily I also discovered that I was compiling in debug mode, which has a bunch of bound checks and so for arrays which are VERY slow. When I made a normal build, the simulation was pretty fast again, but not fast enough. Then I realized that... Well, I'm dealing with large water masses here. A pixel (which represents a tile) is probably a cubic meters of water. Running the simulation 10 times per frame just looks good when looking at the entire map from a distance, but Zoomed in, a tile could potentially travel 10px per frame this way. So I just run the sim one time per frame now, and I'm back to 0.5ms or so. This way waves will jitter around less too.
-
Yay, so much progress today.
Flowing water and BG tones in the game. I had to slow down the water even more, from 10x to 1x to 1/8th. Probably doesn't use the CPU notably at all now.
The BG tones are not some simple transparency. Instead I can set light and shade color for each sky type. Water is a bit square still. You can see the homeless water surface blocks.
(http://androidarts.com/smb/flowing%20water%20and%20bg%20tones.png)
-
Oh, one thing I forgot to mention.
When playing the demo I noticed that you can not run through a single block gap. That just feels wrong as far as Mario goes to me. Small Mario is 1 block high and Super Mario 2 blocks, which works very well in the original games. Something to consider.
-
You mean that you can't glide under a block? Or run over single blocks placed like a [...] ? Both these issues are mentioned in the readme.
I'm actually doing big Mario first because it's more difficult. Since he's taller than a block, I have to check more side collision spots.
I had to get ducking in there too, but right now it's only an animation. Not sure if small Mario can duck.
It will take some work to get the collision spot system to comply with ducking. For example, if a block is placed on Marios head, he should probably auto duck
and not be able to stand up. When ducked, he must be able to move so he can't slide into tunnels and get stuck. The original game solved this with a quirk in the collision engine
I guess. I might have to implement crawling.
Since all actors will eventually share the collision engine, I'll have to make sure that it runs fast. Right now I'm leaning towards making several hard coded versions of it which characters of different size and ability can use. A dynamic engine with lots of variables will probably be too slow if I'm to simulate all enemies persistently. I'm not sure if I'll be able to do that anyways with my current system. I might have to put enemies far away to sleep.
(http://androidarts.com/gamedev/trace.jpg)
I found this image. It describes the anti tunneling feature. It enables me to use high velocities without risking cutting though corners or even entire blocks. It's however slower than many other collision systems. I think big Mario now checks the corners pointing in the direction of his velocity, so 5 out of 6 points. I use a fixed point system with a 16bit 'bit shift' (64k).
Today I'll try to implement a water surface smoothing algorithm I think. I tried a simple one yesterday but it made 50% noise surfaces too wavy and jittery. I'm thinking that I can possibly find lateral neigbours with a wider search, then average those a bit... It looked really cute when I made a little sliding water face-hill though.
-
I meant running underneath a block. I have not read the whole doc. :y:
-
AHA!
I think the core of my problem is that my water quanta are too large. I run my sim every 8th frame now to prevent if from being too fast and jittery. At the same time I have the problem of water chunks being too large and boolean.
What if each cell had like a water mass of 0-3? Then the simulation could run more often (affordable), but leak smaller packages of water.
(http://androidarts.com/smb/water.gif)
This would mean that I'd have to draw an absolutely enormous water tile table though. Too large with 4...5, 9 whatever cells and 4 water volumes. There might be a way to generate blobs on the fly. That, or I can keep all flying water chunks spherical (disregarding neighbor situations), and just do a more detailed test for obvious lateral water surfaces, if possible. Whenever I try a solution there's always some quirk I didn't think of.
I might do something else now though. Water is functionally there, it just doesn't look too hot.
I'm using BlitzMax.
-
Here's an idea that pooped up. Because water evens out, this kind of solution might only look square for a little while. SMB isn't too bothered by square either. Later the difference in height (1/16th tile) will be so small that the surface will looked smoothed out.
(http://androidarts.com/smb/water_height.jpg)
Also, this way I can do rain with small droplets.
Edit: It worked. Now in the game!
(http://androidarts.com/smb/water_levels.png)
Some jaggies but they disappear very quickly as the water evens out. I also animate the surface with gliding waves (4 frames).
-
New build (0.07a) (http://androidarts.com/smb/). Might be a little slow up in the night sky area. I haven't optimized drawing yet. Water... kind of works. but I really need a pressure/push system to prevent it from piling up. Averaging only helps a little. Alternatively I could try some method of rushing water laterally until it's no longer downhill.
Edit: And some pixel stuff from yesterday. I don't think I'll do much crossover stuff, as it hurts the solidity of the universe. Failed to do thrones/bases. I'll use my chozoroom-bot instead.
(http://androidarts.com/smb/other.gif)
-
I just wanna say that while I've been loving your work here, the fact you made Megaman bulkier than Samus in her suit confuses me.
-
I think..water should always run unless it's leveled.
I flood randomly and get a pile of water on one side but none on the other...what's up with that?
(http://androidarts.com/smb/water_levels.png) this is exactly what shouldnt happen,the water to the right of the actor should be at the same level as the water to the left. Theoretically the actor should have some air over his head, but if you have to chose between that and evening the water at the two sides, but if you have to chose between that and evening out the water eliminate the air pocket...it's just incredibly unintuitive now. (I'm sure I've seen a blog discussing it somewhere...maybe it was wolfire's?)
I dont think this souldnt be drawn with tiles, I mean with something like Pixeljunk shooter out there I see little point to doing this if you cant do it at their level. Are you posting this at any straight coder board? I dont think we have much of use to say here, if you do maybe you can recruit someone who can code fluids.
-
Conceit: He mentioned needing some pressure/push mechanics for the water. Also making a proper fluid dynamics engine if it is not a major part of the game would be a little bit over the top, also they are quite processor intensive.
-
Well, I didn't mean to start coding this. I just wanted to draw some SMB sprites and it escalated. I'll guess I'll migrate to tigsource now.
It's very difficult to do proper fluid mechanics. I've tried a particle based one for another project, but it didn't go well. Like I said, I believe just having something fluid to play with is fun already.
Maybe I'll recolor it bubbly green and call it slime, or just do chunky lava gfx for it. People won't expect it to do watery things then. But water for the fishies and bridge area would still be nice. I was thinking of filling the crater in the center with water, and you pull the plug and drain it, or something.
I've uploaded v0.08a
http://androidarts.com/smb/
NEW:
- Tile rendering suddenly 10 times faster.
- Scroll locking. Evaluate with E key after editing. The scroll
lock evaluator will look at screen edges and determine if there's
a wall/floor/roof. Edges have to be on multiples of screens. - Primitive Joypad support. (+ pad and 2 buttons)
- Crawl like a monkey.
- Squeeze in under low blocks. And jump under them.
- Look up and down while grounded (if scroll lock allows).
- Wall climbing and jumping. (Hold walk key and press away from the wall and jump.)
Edit: New thread (http://forums.tigsource.com/index.php?topic=14963.0)
-
I started doing new basic ground blocks.
6 top (lit), 6 mid, 6 bottom (shaded). I'll do these in several colors I think.
I tried out a green tone for my dungeon colored blocks. It gives an ancient feel. However, I felt a little bad about adding another color. It's not teal like the dungeons are supposed to be. Also, now I have a green which I could've used on the pipe, but I don't want to really.
So, I merged my darkest shadow color with the black to push the graphical effect a little and reduce colors. Looks kind of harsh though, and it will eat up the outlines of the figures. I'm not sure what to think. What do you think?
(http://androidarts.com/smb/green.png)
-
Just a little test.. Still 12 colours, but I made an extra green, created a warmer palette, reduced the background layer detail (quickly!) and added warmer coloured shadows around most things instead of the black. Just playing around really, I don't expect this to be used.. :)
(http://www.retroidea.com/Pictures/smb1.png)
-
Used yellow and removed the pink to recover the darker blue. Also added more coloured outlines and tweaked the palette a bit..
(http://www.retroidea.com/Pictures/smb2.png)
-
The colored outlines really improve your sprites :). I'm happy that you kept the second blue, as it adds depth to the background IMO (besides the detail of course).
-
While the additional color in the tubes and the sprites is a real improvement, it breaks the NES restrictions, doesn't it? (3 colors + background for a tile or 3 colors + transparency for a sprite)
-
I think the colours happymonster used for the outlines are too close to the internal colours and thus cost the sprite volume and readability. They just kinda merge together.
Arne is not caring too much about NES restrictions here anyway. He has more tile palettes as possible, same for sprite ones. Who cares, it's not like he is making a NES game.
-
Yeah, right now I'm just trying to keep keep some kind of NES'y graphical punch in there, so I prefer the black. I did change the tree/bush outline to a dark color. The tree really shouldn't look like it belongs in the FG, but I still like that it's green. Maybe I'll use a similar approach for other BG things. I want to keep the black for the blocks and characters.
I changed the palette around a bit. Not happy with the daylight purple shadow and the calculated +1,+1 drop shadow on the BG blocks doesn't look good in the daylight situation. Water is now drawn with 70% opacity but I forgot to add some here.
(http://androidarts.com/smb/splitscreen.png)
For the next build I might have multiplayer (with simple tag?), but actor-actor collisions might be hard to pull off properly.
-
Have collision only happen with leg --> cap interaction?
That way you could walk through eachtoher but still be able to cooperate on jumps and such.
-
This thread is pure win Arne. I couldn't resist making a little edit of one of your mario guys. I tried to make a goblin as well but I think he needs to be thicker to read correctly, not sure.
(http://home.comcast.net/~bedelf/pixelation/100410/1smb_goblin_and_gerard.png)
Sorry, not trying to hijack the thread here. Just was inspired by this thread to make these. Animated today:
(http://home.comcast.net/~bedelf/pixelation/100510/1smb_gerard_standing.png)(http://home.comcast.net/~bedelf/pixelation/100510/1smb_gerard_walk.gif)(http://home.comcast.net/~bedelf/pixelation/100510/1smb_gerard_run.gif)