The VG Resource

Full Version: The Spriters Roguelike
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
[Image: a3a0bfc32b0a2bf7c320b6317522055f.png]

(07-03-2016, 04:17 PM)Kaimatakitaki Wrote: [ -> ][Image: LIMevUx.png]
These little sprites seem like a good way to practice shapes without them getting out of control.

Also yes. Pixelart is not about "retro-looking graphics" in my opinion.

It's a test of readability and efficient character design. If you can manage to make something good and understandable in this size, this is a signal of good design.

I like your sprite, but the dark blue/purple scheme kind of melts together. Perhaps playing with the colors will help?
It's like you guys never tried to make a game before. You guys should keep at least 1pxl offsets between sprites and put a background box too so it's easier for us programmers to play with em.

[Image: 3zwQZKq.png][Image: W5JVxnJ.png][Image: RPoLRJD.gif]
The sheets are split based one which the objects that need depth, excluding flat floors and roof tops. In the gif, you can see the subtle depth in the stove, table, bed and chest.
this is actually cool and stuff but roguelikes do tile-based movement if i'm not mistaken - there's no need to program layerings in objects

of course, awesome job as always. you shall be known for your efforts.
(07-04-2016, 03:20 PM)TheShyGuy Wrote: [ -> ]You guys should keep at least 1pxl offsets between sprites
Uhh, no you shouldn't lol.  The math is simpler if you have the sprites their exact width apart instead of an additional +1 everytime.  sprLeft = sprWidth * frame, instead of sprLeft = (sprWidth * frame) + frame. It might be easier to look at visually, but it's more calculations on the computers part in the code, that has to happen every frame, to do it that way.

Other than that, cool that you put the sprites in an engine so far.  As an aside, though, the movement looks too slow itself.  Walking at the pace of a leisurely beach stroll.
Dang, the layering part is the only interesting gimmick on the programming end for me. Other than that it's just a normal and simple game =/

@Koh: With the 1 pxl offset, it's simpler to grab the sprites automatically from Unity.. .though I could have used the grid tool. Also, by having a 1 pixel offset, you avoid any possible pixel bleeding that may happen when you rotate or scale the sprite (but I realize that's unlikely in this game). Also, that additional math doesn't seem too complicated:

sprLeft = (sprWidth * frame) + frame == (sprWidth + 1) * frame

I should say that I'm just having fun and I'm not planning on dedicating a lot of time to this.
It's simple math, yes, but it's additional calculations that don't need to happen in the long run if the sprites were just placed their proper bounding box length apart in the sheet every frame (like say, every frame fit in a 16x16 space, they should be within that grid on the sheet itself). Optimization; the less overhead the better. Especially if it runs at 60 FPS.
You may still run into potential bleeding problems. I also wouldn't call that a significant overhead that would ever effect a game from running at 60fps
I don't want to know programming tech right now at the moment, this thread is simply supposed to be an art thread.

however if you want to experiment with the sprites, go ahead! Maybe you can surprise us all! We're all here to have fun.
[Image: VBrMald.png]
[Image: uIhuFwp.gif] [Image: CFEjgbq.gif] [Image: RzWLeuW.gif]
your sprite is off-style, there should only by one frame for both up and down sprites (though this is easily done by only mirroring one frame). Good job though
[Image: No6UB9H.png]
Hopefully this fixes the problem.
Is there a palette or number of colors I should stick to? Or shading style?
(07-04-2016, 03:20 PM)TheShyGuy Wrote: [ -> ]It's like you guys never tried to make a game before. You guys should keep at least 1pxl offsets between sprites and put a background box too so it's easier for us programmers to play with em.

I know Gors said he doesn't want to talk about programming tech here but I just want to quickly say that it really depends on the tool. For the engine I use it's generally easier if the sprites have no gaps, and I've never experienced pixel bleeding issues when rotating.

Anyway, this is really cool stuff guys! I might mess around with coding something for these as well, or even *gasp* try make some myself Surprise
I'll agree and apologize. I forgot that bleeding is also related to the blending used (https://www.youtube.com/watch?v=dU9AXzCabiM) and whether you render with non integer values. For my uses, I had to make simple 3D models of the sprites that may need depth. If any sprite was adjacent to another without space, my vertex UVs may show the incorrect pixel due to sampling error.

(just showing the 3D so this post is more interesting to look at)
[Image: 026vvh1.png]
It would have been fun to play with sprites that worked well with overlapping, like high grass, water, or somehow emphasize the 3D, through lighting, physics, or w/e.
What engine are you using for the 3D? And, also, my question above.
Pages: 1 2 3