Zeran's Folly

[myroidtc]

Zeran's Folly is a story-based action-adventure platformer with fluid combat and a weird sense of humor.

The game is being built in C++ and uses a custom engine. Except for networking, I use all of the SFML modules: graphics, window, system, and audio. I enjoy SFML because, well, it's simple and fast but also includes a bunch of useful little features.

I came to SFML from Flash back in 2013. At first I missed some of the basic engine stuff from Flash like rendering and asset management but I've grown to love the power and flexibility that SFML offers. One of my favorite parts is shaders--you can get some awesome effects out of them if you get creative. For example, I use shaders for the wavy water effects, some bloom here and there, and as a method to tint the level art in some sections of the game, mostly in the Manastery area. You can check out the effect in the "Miracle Juno Boss Fight" video below.

Zeran's Folly is out! Check it: http://store.steampowered.com/app/665030/Zerans_Folly/




Some pretty pictures:







Here's a bunch of videos:

The first few minutes:


Lone Clone boss fight:


Final dungeon gameplay:


Miracle Juno boss fight:


Let me know what you think!

IndieDB: Zeran's Folly
Twitter: @myroidtc
Subreddit: /r/ZeransFolly

[Jesper Juhl]

Wow. Although this is not really my kind of game, it looks really well done and the video is amazing.
Love the graphics.
Great work.

[dwarfman78]

This is sweet, it reminds me of Sonic The hedgehog in a way.

[Geheim]

This is by far the most complete project I've seen so far and it looks awesome!
Seems like a lot of fun to play and I definitely would love to play this!

You and your team did a very great job on this one and the graphics really look great.
The only annoying thing is the sound of the coins
Keep us updated on this masterpiece!

[myroidtc]

Wow. Although this is not really my kind of game, it looks really well done and the video is amazing.

Thanks!

For those of you who are on the fence, the gameplay shown in the video is from a sidequest that is more of the traditional "collect coins and beat the stage" deal. The main game is more Zelda-y in that you go to a place, beat a dungeon, maybe get a new power, go to the next place, and so on. Millie Megavolte 6, another game I made, was like this.

This is sweet, it reminds me of Sonic The hedgehog in a way.

Yeah, Sonic is one of my biggest influences. In fact, the physics engine is an implementation of the Sonic engine from the Genesis games. Check out Sonic Retro, they did a really good job explaining the Sonic physics engine.

Originally I just wanted a way for characters to go up slopes at the correct speed but I guess I went a little nuts with it, heh.

You and your team did a very great job on this one and the graphics really look great.
The only annoying thing is the sound of the coins
Keep us updated on this masterpiece!

Thank you! Tori Kamal and Izzy Dulay did a great job with the voices. Everything else on screen (except a good chunk of the sound effects) is my handiwork, from the art to the programming to the music. I guess I can't brag about the coin pickup sound being any good though, heh.

[Clockwork]

Wow!  That looks like it could be a great app (I would absolutely download it if it was).

Oh, and if you don't mind me asking, what did you use to make the maps?  Was it TiledMapEditor or your own level editor?

[myroidtc]

Oh, and if you don't mind me asking, what did you use to make the maps?  Was it TiledMapEditor or your own level editor?

The foreground is split into three layers: midground (behind the character), foreground, and collision mask. All three are big ol' textures, which is why the levels are broken up into sections rather than continuous. While incredibly easy to work with (just draw some stuff in an image editor and boom, level), it's incredibly taxing on memory and load times. If I keep going with this method I'll have to rework it in some ways because I've noticed lower-end machines have problems with missing textures.

I do most of my "level editing" with Flash. I use it to make the collision masks and I made a script to output object positioning code that I can insert directly into the C++ source.

[zmertens]

That looks awesome. I definitely got a Sonic vibe from it too. It should be on Steam!

[BaneTrapper]

I think i would enjoy thins quite. Nice smooth game play!

[Mario]

I like it so far, but I've got two things that I'm not that happy with:

• Plenty of health: Maybe I'm a bit too old-school for this, but the amount of health appears to be a bit extreme.
• Lack of contrast: Looking at the levels shown, it's either all green, all blue, or all brown. Especially at high speeds it appears to become a blurry mess. I think the game has been heavily influenced by the classic Sonic games (especially those loopings), so I'd say look back at the Sonic games: There's always quite some high contrast, e.g. blue sky, brown background, and green platforms (and a blue character).

[myroidtc]

Plenty of health: Maybe I'm a bit too old-school for this, but the amount of health appears to be a bit extreme.

Like, as in appearance-wise, or difficulty-wise? According to the feedback, there was a wide spectrum of perceived difficulty but it tended to skew towards fairly difficult. Plus, keep in mind that I know the game inside and out (obviously) so I didn't need that much health in the video.

But, rest assured it won't seem like much on the higher difficulties. (Mostly more damage taken, most enemies and bosses have extra/harsher abilities, etc)

Lack of contrast: Looking at the levels shown, it's either all green, all blue, or all brown. Especially at high speeds it appears to become a blurry mess. I think the game has been heavily influenced by the classic Sonic games (especially those loopings), so I'd say look back at the Sonic games: There's always quite some high contrast, e.g. blue sky, brown background, and green platforms (and a blue character).

That's a good tip! I'll keep it in mind.

[cm3rt]

Very cool. You did an excellent job. I really enjoy the familiar feel to Sonic the Hedgehog. One question I have regarding the engine: do you have any tips or tutorials on actually making the game side scrolling? Meaning, how do you stream the map from left to right? Obviously this is a fundamental question of side scrolling games and I don't expect a thorough explanation, but I really would like more information on how this is done.

[myroidtc]

how do you stream the map from left to right?

Think of it as having two representations of your game world: logical, and on-screen. A character may have an X position of 1500 but it may have an on-screen position of 300 depending on where the camera is.

object.onScreenPosition = object.absolutePosition + camera.offset;

So, in your draw function, you position the sprites on-screen depending on their distance from the camera rather than on their absolute position. By moving the camera or having it "track" an object, you can move the object around and the world will appear to follow them, scrolling the map.

[cm3rt]

Ah that makes perfect sense. Thank you so much.

So one last question that goes along with that, I think:

If the world in which you're scrolling through with relative positioning of objects, do you load the resources of the objects when they are, say, 1000 > x > -1000 AND 1000 > y > -1000 position units away from the main character (the center of the screen), and anything outside of those bounds unload it?

Also, do you have the absolute positions of every object stored inside some sort of database so that you know which objects to load the resources of and display as you get close to that object?

Thanks so much again,

cm3rt

[myroidtc]

Also, do you have the absolute positions of every object stored inside some sort of database so that you know which objects to load the resources of and display as you get close to that object?

Movable objects in the game (like coins, the characters, particles, etc.) derive from a Mobile class. Mobiles have an sf::Sprite member that gets drawn when draw() is called on the Mobile. Mobiles also contain other data like its absolute position, animation data, velocity data, and so on. If the Mobile is going to be used that level, such as the bee enemies in the grasslands level, its textures will be loaded or pointed to.

That will help explain the next part:

If the world in which you're scrolling through with relative positioning of objects, do you load the resources of the objects when they are, say, 1000 > x > -1000 AND 1000 > y > -1000 position units away from the main character (the center of the screen), and anything outside of those bounds unload it?

The issue here is not loading/unloading resources, which is a different beast altogether. Instead, it's about calling draw() on an object or not (i.e. culling). The way it works in Zeran's Folly is fairly simple:

-Set the sf::Sprite's position to the Mobile's absolute position modified by the camera offset. This will be its "screen" position.
-Is the sf::Sprite's getGlobalBounds() inside the screen, therefore (probably) visible? If so, call draw() on it. If not, don't.

TL;DR: Don't mess with loading/unloading textures, just don't call draw() on stuff that won't be seen. sf::Sprites are contained in another class that has absolute position data--no database is used.