Messages

31

SFML projects / Re: Zeran's Folly

« on: July 03, 2014, 10:03:32 pm »

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.

32

SFML projects / Re: Zeran's Folly

« on: June 27, 2014, 10:47:42 am »

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.

33

SFML projects / Re: Zeran's Folly

« on: June 27, 2014, 04:25:42 am »

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.

34

SFML projects / Re: Zeran's Folly

« on: June 23, 2014, 08:45:57 pm »

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.

35

SFML projects / Re: Zeran's Folly

« on: June 23, 2014, 07:25:48 pm »

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.

36

SFML projects / Zeran's Folly

« on: June 23, 2014, 04:47:52 am »

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

37

Window / Re: Joystick PoV Axes Flipped

« on: November 18, 2013, 08:47:14 am »

It seems to be just SFML. The hat works as expected in the Windows calibration thing and some other applications like JoyToKey and PCSX2 correctly detect the hat direction.

When pressing "up" on the dpad,

sf::Joystick::getAxisPosition(currentJoystick, sf::Joystick::Axis::PovX)

returns -100.0 while "down" returns 100.0. Note that it's PovX and not PovY.

38

Window / Joystick PoV Axes Flipped

« on: November 18, 2013, 07:02:51 am »

I'm using SFML 2.1 Visual C++ 11 (2012) - 64 bits and Windows 7.

sf::Joystick::Axis::PovX corresponds to the d-pad vertical instead of the horizontal for me. I've tested with two controllers (DualShock 4 and Xbox 360) and the axis names are consistently flipped. All the other axes are fine.

Is this a bug or are the names arbitrary? Might the OS have something to do with it? It's not that big of a deal, I'm simply curious as to why this might happen.