Author Topic: My SFML project - shoot 'em up game (Read 13138 times)

Sivak · « **on:** March 21, 2010, 04:46:05 am »

Well, I saw this and figured I'd share.

I've made some games in the past, but those were done in assembly. I've decided to move up in the world and try my luck with C++ and SFML.

I'm intending to make my own shoot 'em up game, currently dubbed "Shmuppy". I'll think of a title later.

I want it to be manic where there's lots of bullets all over the place (like 500+). Thus far, I've gotten a few screen transitions to work, so I'm pretty pleased with that. It's a lot farther than I've ever gotten with anything in C++. Doing the actual game itself will certainly be interesting.

SFML has made things relatively simple thus far. Hope it stays this way.

Walker · « **Reply #1 on:** March 21, 2010, 06:52:22 am »

The graphics/sound/input (bits you will use SFML for) are the easy part :lol:

I think most people struggle working out how to do "levels" - enemy movement, bosses etc.

By the way, that kind of shmup is usually referred to as "bullet hell". If you haven't seen it, 'Perfect Cherry Blossom' is definitely worth a look as far as bullet hell shmups go. Probably one of the best looking shmups ever IMO.

Sivak · « **Reply #2 on:** March 21, 2010, 05:08:56 pm »

Hi. I've beaten the extra stage on PCB. The Touhou games are part of the inspiration for this in the first place.

I don't think the enemies themselves would be too bad. It's the bullet patterns one needs to dodge and having more complex ones on higher difficulties... I'm almost wondering if it'll be "too easy" since I tend not to beat most of these games on anything but normal.

Only time will tell.

Grandmaster B · « **Reply #3 on:** March 22, 2010, 08:46:41 pm »

I try to learn Assembler for years i simply dont get into it. Walker is right, the graphics, sound and input are the easy part and the game logic can be pretty hard.

Sivak · « **Reply #4 on:** March 30, 2010, 06:42:14 am »

Hey all, thought I'd show off a demo finally. You can't do a whole lot yet, but it's a start!

Basically, it'll show a message box and then skulls endlessly spawn. They can be killed.

Controls: Z to shoot, shift to move slower.

http://sivak.nintendoage.com/Shmuppy.zip

Hoping it runs fine for you folks.

Sivak · « **Reply #5 on:** April 09, 2010, 06:36:52 am »

I updated the zip file in the message above this. Just wondered if anyone could test and report speeds. Thanks.

Breakman79 · « **Reply #6 on:** April 09, 2010, 06:54:41 am »

Runs perfectly fine on my computer where it reads a constant 66.6 fps. The number of bullets on screen at once is terrifying! I die in like 2 seconds. 0_0

Sivak · « **Reply #7 on:** April 09, 2010, 07:56:27 am »

Quote from: "Breakman79"

Runs perfectly fine on my computer where it reads a constant 66.6 fps. The number of bullets on screen at once is terrifying! I die in like 2 seconds. 0_0

Well, it'll be a bit more reasonable in the real deal. I was just messing around with stuff for this.

66.6 eh? It's 64 for me... I'm definitely hoping to find a way to better regulate this... :?

Mindiell · « **Reply #8 on:** April 09, 2010, 09:24:32 am »

Quote from: "Sivak"

66.6 eh? It's 64 for me... I'm definitely hoping to find a way to better regulate this... :?

66.6 => 1 frame every 0.015015... second
64 => 1 frame every 0.015625 second

Sounds like it's just no matter at all, this is insignificant at this rate. You better try to upgrade your game, ennemies, tactics, music, sounds, gfx, etc...

Sivak · « **Reply #9 on:** April 09, 2010, 06:18:49 pm »

Yeah, I know it's not a big difference. I guess having it be locked or "mostly locked" is just something I'm obsessing over.

Laurent · « **Reply #10 on:** April 09, 2010, 06:28:26 pm »

The current operating systems are not accurate enough, then can't offer such a good timing. It is actually very hard to get a fixed steady framerate.

Sivak · « **Reply #11 on:** April 09, 2010, 06:43:51 pm »

I see, well, 64-65 isn't bad.

The main reason why I'm obsessing over this is because it's the way I'm used to counting things.

For instance, I have the player move at 4 pixels every FRAME. I use the frames for counters, etc.

I've gotten accustomed to: 15 frames = .25 seconds. 180 frames = 3 seconds, etc.

With the faster frame rate, it'll obviously be speedy and lower it'll be slow. I guess I could look into trying to use the clock objects, though would I need to have one of those with everything? That's the main reason why I didn't bother with those as I didn't really get using them.

Spidyy · « **Reply #12 on:** April 09, 2010, 06:49:20 pm »

I'll guid you to this : http://gafferongames.com/game-physics/fix-your-timestep/

Read this document, it will help you like it have helped me. :p

Also, if you wish to absolutely keep a 60 fps frame rate, you can try to search in the sources of this game : http://i-saint.skr.jp/exception_conflict/#download

This guy use a strange technique with an internal scheduler and have a pure 60 fps with openGL, BUT the game run at full speed (meaning 100% CPU).

Sivak · « **Reply #13 on:** April 14, 2010, 06:56:32 am »

Hey guys. I've modded this with a new time control scheme. I'm wondering how it runs on your systems. Reports appreciated, thanks.

Download link is the same.

Note: The in-game FPS is currently inaccurate. If you have Fraps or something that can count FPS, that'll be more reliable.

KNOWN ISSUE: If you drag the window, the game can go insane fast due to being "paused" briefly. I'll be working on fixing this. So try not to drag it while testing.

Breakman79 · « **Reply #14 on:** April 14, 2010, 07:16:36 am »

I seem to get anywhere from 59.1 to 60.3 now. Although, it appears as if most of the slow down I get is because of all of the debug output to the console.