Hard Light Productions Forums
Off-Topic Discussion => Gaming Discussion => Topic started by: Colonol Dekker on February 07, 2013, 10:53:29 am
-
Frogatto (http://www.frogatto.com), is an open-source FREE platformer.
(http://www.frogatto.com/screenshot_imgs/v_1_3/moonlit_ramparts.png)
The reason it caugt my eye is that it has a quite modddable engine.
I could see a nice little shivan/vasudan character-based game (http://www.frogatto.com/developer) as soon as i noticed the open-sauciness of it, I thought... One of the guys here must have / or the abilty to knock up a sprite-sheet.
(Even a reskin of an old super metroid baddy might work)
-
doubtless, but why waste even that much effort on a generic platformer with generic low-fi graphics
-
Yeah, it has a very nice, modern, fast and moddable engine and apparently you could do almost any kind of 2D games with it.
-
doubtless, but why waste even that much effort on a generic platformer with generic low-fi graphics
Because, we choose to.
Yeah, it has a very nice, modern, fast and moddable engine and apparently you could do almost any kind of 2D games with it.
Looks worth a play with right?
I remember playing with this (http://www.adventuregamestudio.co.uk) to make an FS based adventure.. Didn't get past making a Bastion mainhall with giant controllable engineer :lol:
-
Why waste even that much effort on a generic space-sim with generic low-fi graphics?
-
that would be much cleverer if the space sim genre was swamped, or if fs2's graphics were actually low-fi for the time
-
Wait, what? What game has low-fi graphics? Frogatto doesn't, it has really pretty and sophisticated graphics.
-
I'm not talking about remaking freespace, maybe a spin-off about Carl? Anything :)
-
doubtless, but why waste even that much effort on a generic platformer with generic low-fi graphics
...
that would be much cleverer if the space sim genre was swamped, or if fs2's graphics were actually low-fi for the time
...
For the time and genre that this game is emulating, it is pretty good. Now if you don't mind, there's modders discussing how much fun it'd be to mod this game
And yes, a spin off with Carl would be hilariously awesome.
-
I think they mean it's generic low-fi graphics mostly because it has the moveable foreground. And a fairly static background.
Which honest, it a design decison in the game. We've just become to adjusted to larger, 3D type environments where we can move anyway we like, rather than just side scrolling.
Would Mr. Carl have a certain beam that he could use to... you know... f**k everything up?
-
i mean generic low-fi graphics in that it's the same "i don't have to make good art, i'll just slap some programmer graphics on everything and call it retro!" crap that so many indie devs try to pull -- dammit i was trying not to get into a pointless argument about this
-
dammit i was trying not to get into a pointless argument about this
Stellar job there :p
-
i mean generic low-fi graphics in that it's the same "i don't have to make good art, i'll just slap some programmer graphics on everything and call it retro!" crap that so many indie devs try to pull -- dammit i was trying not to get into a pointless argument about this
Which "indie devs" are you talking about? Because I've seen some incredible work done with side-scrollers and sprites.
-
the ones that don't do that
-
Combat: Have Carl do melee attacks with several combos (use those sword things from hall fight.) Even pick up GTA/PVN marines and throw them around for good measure. While fighting, you charge up a super bar and... (http://www.youtube.com/watch?feature=player_detailpage&v=gcWhhsRGsAI#t=119s)
As a taunt, you can rave like that Shivan behind the one firing his laza. :p
Just my 2 cents.
-
the ones that don't do that
quite a profound statement, my views on the subject have been swayed by your example.
-
Why waste even that much effort on a generic space-sim with generic low-fi graphics?
Combat: Have Carl do melee attacks with several combos (use those sword things from hall fight.) Even pick up GTA/PVN marines and throw them around for good measure. While fighting, you charge up a super bar and... (http://www.youtube.com/watch?feature=player_detailpage&v=gcWhhsRGsAI#t=119s)
As a taunt, you can rave like that Shivan behind the one firing his laza. :p
Just my 2 cents.
glad to have you on board. :P
-
So, it's a given that at least some of us would be interested in a "Carl's Hallfight bonanza" 2D platformer?
-
Hell Yes. GOTY-Carl Edition
-
i mean generic low-fi graphics in that it's the same "i don't have to make good art, i'll just slap some programmer graphics on everything and call it retro!" crap that so many indie devs try to pull -- dammit i was trying not to get into a pointless argument about this
If you're referring to Frogatto, then I'm sorry but you simply have no idea whatsoever what you're talking about. Pixel art and programmer art are two completely different things, and I can assure you that Frogatto only has the former.
-
IMAGE FORMAT SPECIFIC INFO-
Images
for objects:
Frogatto only supports one image type: PNGs. JPEG support might be reasonable, and our libraries would support it with some additional work, but you'll need to come to us with a compelling use case before we add the feature (this isn't a show-stopper for you; it'll just eat up some additional data space).
We may have issues with PNG8 files, we encourage everyone to use PNG24 files.
We rarely use it ourselves, but we do have full support for PNG alpha channels. What we use instead, and which is more convenient for pixel-art, is a pair of "magic colors". Any pixel with the RGB values #f9303d or #6f6d51 will be made entirely transparent in the game. The biggest benefit of magic-colors is it allowing us to annotate directly in the images; primarily, we use this to draw the frame bounds images are sliced at, since visually figuring out where they are from the actual markup is time-consuming and error prone - as is lining up images in a spritesheet without these.
It's possible to reference an animation in which every frame is a separate image, but we have a slew of conveniences for what are called "spritesheets": series of animation frames arranged in rows and columns, all within as few images (often just one) as possible. You're encouraged to use spritesheets for all animations.
We have a few limitations on image size; first, all image files must be an even number of pixels in both dimensions (the files themselves, not the animations on them. Second, if you're going to repeat an image (in the manner used by ropes, or our parallax backgrounds), it needs to be a power-of-two along the dimension that repeats.
For memory usage, it's encouraged that you don't exceed "power-of-two" boundaries by a small amount, because the game will internally expand that texture to the full limit of the next po2 unit in that dimension; for example, if you have a texture that's 533 pixels wide, the game will pad it to a full 1024 pixels wide, internally. In memory, another 512x512 block of uncompressed 32bpp data is 2 megabytes in size, so this can really add up. Naturally, this is barely an issue with small powers-of-two like going from 32x32->32x64; you should only worry about this at sizes about 512x512px. Generally, if you're exceeding 512x512, you should just make another spritesheet for the additional animations.
We do have a system for compiling images into enormous texture atlases, so you shouldn't knock yourself out optimizing your spritesheets by hand. It's a waste of time, the script will do better than you can ever hope to. Optimize your spritesheets for human readability, and ease-of-editing, not size.
for backgrounds:
As mentioned above, backgrounds have a restriction that they have to be a power-of-two in the direction they repeat in. Backgrounds will always repeat horizontally, but whether they repeat vertically is optional (this can be set separately for up and down; a background can start at a certain height, and only repeat in one direction). Background images thus always have to be a power-of-two horizontally, but vertically is a matter of whether you need them to repeat. Backgrounds that don't need to repeat vertically can be stacked together in a single image.
Backgrounds are layered in the order they're drawn in; later things go on top. For optimization reasons, you're encouraged to put large blocks of stuff that need to be drawn as a batch, all in the same image (like our layers that comprise the ocean in frogatto). This way, they can all be drawn as one operation.
Additional background info---
Backgrounds:
Frogatto has special, hard-coded support for parallax backgrounds, and foregrounds, made up of large, repeating graphics. We can have as many layers as you want, our only limitation is that stuff has to be a power-of-two in size (unless it's a small, isolated thing like a cloud separated by empty, transparent space), and our horizontal backgrounds can't stop at a certain point (though this can be faked). Note that our tiles and our objects can also be given parallax, so using the special hardcoded backgrounds is not your only option! Backgrounds are covered in this tutorial TODO.