Saviors - Released in Steam and v1.5

DrInfy · Post by **DrInfy** » Mon Dec 17, 2012 3:16 pm

Saviors is a modern vertical 3D shoot ‘em up following the story of three daredevil pilots. The inevitable first contact with extraterrestrial life may make us believe in things that seem too good to be true. But what happens if everything isn’t as it first seemed like? Includes a fully customizable ship, advanced physics and 18 explosion filled levels in single player or two players co-op mode.

Features:
- 18 full length levels with different environments and enemies
- Physics affect the gameplay in a way that hasn’t been seen before in shooter games
- Destroying enemies creates massive chain explosions affecting all nearby enemies
- Story (yes an actual story in a shooter) which develops until the very end
- 3 different game modes (story mode, survival mode, arcade mode)
- 100 achievements for additional challenge and replay value
- Fun and original 2 player co-op game mode. Players have different weapons and roles and need to work together to succeed
- Enemy warning icons provided by your radar removes the need for excessive memorizing which is present in most shooters
- Replay feature allows you to save your best runs or download those of other players’
- 4 different difficulty levels cover the skill levels from beginner to hardcore veteran players

The game is now available for Windows.

Links:
Steam Store
home page
indiedb page
Desura

ciox · Post by **ciox** » Mon Dec 17, 2012 6:46 pm

I'd like to have a look but your demo build crashes for me without any useful error message, Windows 7.

I like that it's a 4:3 vertizontal though, same choice as my project though the HUD is on both sides.

DrInfy · Post by **DrInfy** » Mon Dec 17, 2012 7:35 pm

Did you install XNA 4.0 and .Net 4.0 ?
Those links are in post in our site, but I'll add those links to the opening post to make sure everyone understands they are required.

ciox · Post by **ciox** » Wed Dec 19, 2012 12:56 pm

Whoops that was it, I must have had older versions of the frameworks.
Game felt alright, didn't have time to play for long but it was enjoyable enough, the Hard difficulty felt about right for me. It could use a basic guide though, like I was surprised when my secondary weapon suddenly ran out.
Dropped you a vote anyway while checking greenlight for more shmups, these games can use all the help.

DrInfy · Post by **DrInfy** » Wed Dec 19, 2012 5:48 pm

I really hate that XNA doesn't give any useful info when one of the framework is missing. Should probably create a separate launcher of some sort that checks whether they are installed. It's a real pain in the ass to explain to people that they are missing the required framework files (you are hardly the first one to encounter that error).

There is a tutorial that briefly explains the game mechanics... :p
Although there should be a warning when player tries to start playing the first time without playing tutorial, but I haven't had the time to implement that just yet.

Thanks for your vote and yeah, it is going to be extremely hard for any shmup to get through the Greenlight popularity contest as the genre is pretty niche. Also most people vote based on videos or screenshots and it is quite hard to make a shmup look all that impressive without blowing the screen full of projectiles which in turn scares a lot of people away... :p

DrInfy · Post by **DrInfy** » Thu Mar 14, 2013 7:43 pm

It's been a while so here's an update.

The game content is done for Saviors and I've spent the last two days actually removing content... Removing boring parts, reducing boss hit points in an attempt to fit all the 18 stages into 45 minutes with more intense action. Some effort has also been spent in toning down insane difficulty and adjusting the arcade score system. I think the current score system for arcade is actually quite fun, even if it was never actually main focus for the development (I'll have to post a video later on about it).

We're trying to release the game during this month for both Windows and XBLIG. After that we'll have to see whether it is worth the effort to add more platforms.

n0rtygames · Post by **n0rtygames** » Thu Mar 14, 2013 9:42 pm

I'm guessing from the screen size - that Tate is basically a no here and I think it would be way too much for anyone to ask, or even complain about your lack of tate due to the sheer awesomeness of how this looks.

I will ask however, is there any 4:3 support? Perhaps removing the side bar and having HUD elements on screen? I could go all Mars Matrix with this.

mystran · Post by **mystran** » Fri Mar 15, 2013 12:02 am

Only tried Arcade mode on "normal." Initial thoughts:

- TONE DOWN THE EXPLOSIONS! FFS! Make them about the same size as the exploding ship, MAX! Right now as soon as the first enemy explodes, it's all just white. When "that famous blog article" says enemies should explode in satisfying way, I doubt it means "blocking you from watching anything else but explosions." They also saturate to white too fast, looking like large white blobs, making it even more boring.

- If crashing into enemies damages you, then enemies must be also visible at all times (or at least a reasonable amount of time). Right now as soon as the first enemy explodes, you can't see anything.

- The ships are ridiculously slow. The slow-down button is useless as even the fastest ships move normally at about the speed that you'd want in slowdown mode.

- Please allow fire button to select stuff in menus. It's confusing having to press enter if you fire with Z.

- The secondary weapon system with limited ammo is just nonsense. [edit: I feel like I should clarify why I said this: cool secondary mechanics are certainly fun, but here I felt the secondaries were on some ship types necessary to kill anything at all in reasonable time, which just made them feel "complicated" rather than "cool special thing"]

I can give more opinionated critique after a few more plays (edit: actually I won't, too boring when you're too slow to catch enemies, and too underpowered to ever kill anything, and there's about 10 bullets and you die mostly from invincible popcorn point-blanking you, or background buildings crashing into you from under explosions.. please rethink your design, i'll go back to trigonometry wars which was actually fun from the beginning).

n0rtygames · Post by **n0rtygames** » Fri Mar 15, 2013 1:45 am

@Mystran
Is there any reason why all 9 of your posts seem to be in the development forum, ranting like a self entitled tit and criticising other peoples work with childish insults thrown in? Congratulations, you've insulted someone elses hard work...:/

Anyway, something you might find a little more positive in terms of critique:

This game will actually do well on XBLIG if it goes up cheap. Seriously well in fact. It's got precisely everything that a casual player would want from a shooter. Gratuitously overboard explosions, a very pronounced soundtrack and it's actually fairly easy. It doesn't care too much about scoring through precision, it just lets you have a giggle. I get this sense that simply staying alive and blasting the shit out of everything mindlessly is the route to success.

I do however - think you've got perhaps one too many game modes. Playing on anything above normal tends to make enemies too hard to kill and it starts to feel a bit awkward. So it is difficult to know what to pick. I didn't have a problem killing anything in normal mode - but above that - enemies were veeeery tough indeed.

Regarding the explosions, at first I thought they were too big myself - but you do get used to them quickly.

Take criticism like the above with a serious pinch of salt. Practically everyone on these boards wants the next Cave style shooter. This is not the full extent of your audience. There are casual players out there who do not get the Cave style of shmups and quite frankly, I would prefer to see variety and choice on XBLIG. I think this is going to appeal to those guys - but I would heavily consider scaling back on some of your gameplay options for a XBLIG release - because ultimately, since this game does look to be very much a game catering for a casual audience - your casual audience is going to be your typical xbox live player. So I wouldn't expect them to absorb everything..

Most people want to just press play and go.

You MIGHT want to tone your explosions down a bit - perhaps multiply all the velocities of your explosions, or their life time by about 0.65f - only because they mask all the little point items that you pick up after killing a bad guy.

Nice lighting and shader code. Nice particle system. 10/10 for graphics coding. I'm guessing this is going to target 30fps on the xbox? Or have you managed to instance most of this stuff and get it running at 60?

Cheers!
Steve

mystran · Post by **mystran** » Fri Mar 15, 2013 2:29 am

n0rtygames wrote:@Mystran
Is there any reason why all 9 of your posts seem to be in the development forum, ranting like a self entitled tit and criticising other peoples work with childish insults thrown in? Congratulations, you've insulted someone elses hard work...:/

Oh, I'm sorry about the tone. For real. Apologizes, it's probably bit of a carry over from other contexts/forums, and it's not about wanting to insult, rather I'm just used to technical things (eg osdev, audio dsp, compilers) and very analytical thinking pulling designs into their components.. anyway apologizes if my tone seemed harsh, that wasn't really the intention. Intention was simply honest critique (since developing or composing or whatever, I personally find it unbelievably frustrating that most people never give any useful advice; you just get a few comments that say "great" or "not bad" and then you wonder what the other 99% thought), in the interest of highlighting issues that might not be obvious for someone "too familiar" with their own work (eg you don't need to see enemies and such in your own game, because you know by heart where they are).

But note taken, I should have phrased myself a bit more politely.

As for dev forum.. well, I don't know. I tend to look at anything and everything from a design point of view, I kinda avoid posting in general discussions a bit, because I know that my opinions tend to be a bit controversial in general. Also I kinda have more interest into upcoming new (potentially early in development) games, than contributing into the hype about the next Cave console port.

n0rtygames · Post by **n0rtygames** » Fri Mar 15, 2013 2:39 am

mystran wrote:Oh, I'm sorry about the tone. For real. Apologizes, it's probably bit of a carry over from other contexts/forums, and it's not about wanting to insult, rather I'm just used to technical things (eg osdev, audio dsp, compilers) and very analytical thinking pulling designs into their components.. anyway apologizes if my tone seemed harsh

Nah, I'm sure it's cool dude. DrInfy is a dev, he knows the score... games are hard and feedback is often harsh. I was just prodding you about it early on... your feedback is pretty solid and I can see you're very interested in development.. it's just that this kind of tone can be really upsetting for a developer when they've unveiled something they've spent years on. This is not to say that you should necessarily sugar coat things, but definitely giving your feedback a proof read does help..... That said it's FAR from being the most obnoxious thing I've seen posted here!

Generally when I work on stuff - I tell everyone I'm working with : "Don't spare feelings, don't hold back - because the general public will be far less forgiving". If anything, you getting worked up just shows passion for the genre and that's really what's needed.

DrInfy · Post by **DrInfy** » Fri Mar 15, 2013 2:55 am

Actually, I don't really mind the insults and in fact I've been looking forward to them. It tells me the player is honest and honest feedback is always valuable, even if I don't agree with it.

In fact I find nothing quite as annoying as people who can't say what they really mean, just bash it all you like!

Please note that the build you guys tried is a bit old, enemies are quite a bit easier to take down in the current version even without having the multiplier up. I'll have to agree that the fire button should be usable to browse menus, I kinda forgot all about it as I use space to fire myself. Indeed the slow down button is more of an optional and isn't required (it should also say so in the description), the reason it stays there is because you can also play the game with an analog stick/controller and it wouldn't be fair if there was no way to slow down your ship with an arcade stick/keyboard.

I find it really interesting that none of players that have tried the game have actually understood the mechanic on the multiplier. Having the multiplier up in "MAX" and "BREAK" modes makes enemy explosions deal damage to other enemies. The enemies aren't any tougher in hard or insane, you probably just didn't have that multiplier high enough. This is something I'll have to rethink a bit.

The game is mostly focused on catering to casuals as they're much more numerous in comparison to hardcore fanatics (that would just buy a Cave game instead anyway), but I still want that hardcore option to exist. Because I want to play that myself!

To be perfectly honest I really really didn't want to make that 4:3 full screen mode and was kind of hoping that people would have bought their sets of wide screen TVs allready...

But I guess I'll have to submit and just do it. The game actually runs solid 120 fps on a very modest laptop, so I'm quite confident I can make this thing run on XBOX360 for 120 fps/720p (I still haven't tested it though, have to get working on it asap). Before someone asks why 120fps, it's because physics are more accurate, there's less input lag (some milliseconds) and there's less screen tearing (V-sync is an evil bitch that creates input lag).

n0rtygames · Post by **n0rtygames** » Fri Mar 15, 2013 3:12 am

DrInfy wrote:The game actually runs solid 120 fps on a very modest laptop, so I'm quite confident I can make this thing run on XBOX360 for 120 fps/720p (I still haven't tested it though, have to get working on it asap). Before someone asks why 120fps, it's because physics are more accurate, there's less input lag (some milliseconds) and there's less screen tearing (V-sync is an evil bitch that creates input lag).

With XNA? On XBLIG? Are you smoking high grade crack?

If you get this beasty running at 120fps - you will possibly be one of the most accomplished developers the platform has ever seen.

I would really get compiling on the xbox ASAP... it'll do things that you are not quite expecting...

n0rtygames · Post by **n0rtygames** » Fri Mar 15, 2013 3:18 am

DrInfy wrote:To be perfectly honest I really really didn't want to make that 4:3 full screen mode and was kind of hoping that people would have bought their sets of wide screen TVs allready...

Also - on that note.. are you sure you're complying with the title safe area guidelines? That's going to make you go potty if you haven't. You'll basically have to allow resizing of your entire game unless you want to do a massive HUD overhaul.

My advice:

Render everything to a single rendertarget, draw that back to the screen in a user defined rectangle that gets set as the game starts up (like old PSX games, y'know?)

Then - to get your 4:3 support, simply add an option for 4:3/16:9 in the options menu and take the 4:3 game area as your source rectangle for redrawing on to the screen instead of 16:9.

If you want to avoid letterboxing and such on non 16:9 resolutions, here's something:

Add this to Game1 - or your equivilent class

Code: Select all

graphics.PreparingDeviceSettings += new EventHandler<PreparingDeviceSettingsEventArgs>(graphics_PreparingDeviceSettings);

Create this block:

Code: Select all

     void graphics_PreparingDeviceSettings(object sender,
        PreparingDeviceSettingsEventArgs e)
        {
            DisplayMode dispMode = GraphicsAdapter.DefaultAdapter.CurrentDisplayMode;

          
                Config.mbCRAPTV = true;
                e.GraphicsDeviceInformation.PresentationParameters.
                      BackBufferFormat = dispMode.Format;
                e.GraphicsDeviceInformation.PresentationParameters.
                    BackBufferHeight = dispMode.Height;
                e.GraphicsDeviceInformation.PresentationParameters.
                    BackBufferWidth = dispMode.Width;
                

                Config.mnCRAPTV_ScreenWidth = dispMode.Width;
                Config.mnCRAPTV_ScreenHeight = dispMode.Height;
                Config.mrCRAPTV_AspectRatio = dispMode.AspectRatio;

            // sad times ;(
                graphics.SynchronizeWithVerticalRetrace = false;
                graphics.PreferMultiSampling = true;
        }

You can now run at any user defined resolution without letterboxing. Just make sure to scale your custom rect to 80% of the total screen estate and you will pass the safe area test.

For all the other main things you need to check for XBLIG, I've made a checklist here..
http://www.n0rty.com/CHECKLIST.jpg

...good luck :0)

DrInfy · Post by **DrInfy** » Fri Mar 15, 2013 3:25 am

n0rtygames wrote:If you get this beasty running at 120fps - you will possibly be one of the most accomplished developers the platform has ever seen.

I would really get compiling on the xbox ASAP... it'll do things that you are not quite expecting...

Oh crap, I really don't like these kind of surprises. We originally intended to release Saviors for Windows Phone 7. I tested a lot of stuff before buying the marketplace license and phones using the emulator. We then bought phones and realized that they are nowhere near powerful enough to run the quality we had in mind. A shmup running 20 fps isn't exactly cool.

The original intention was to release PC version first and XBOX360 after that, but we've just now decided to go for as simultaneous launch as possible. I've read about the stuff that Xbox version requires, but haven't put any effort towards it just yet.

DrInfy · Post by **DrInfy** » Fri Mar 15, 2013 3:49 am

We already have quite nice logic in game that allows the HUD bar to scale between 16:9 and 16:10. Just have to extend that logic towards 4:3 and letterboxing those title safe areas. That's the easy part, problem is I'll have to redesign the UI for the 4:3 and also some texts are barely (or not at all) readable at 640x480. Damn ancient technology!

n0rtygames · Post by **n0rtygames** » Fri Mar 15, 2013 3:55 am

DrInfy wrote:We already have quite nice logic in game that allows the HUD bar to scale between 16:9 and 16:10. Just have to extend that logic towards 4:3 and letterboxing those title safe areas. That's the easy part, problem is I'll have to redesign the UI for the 4:3 and also some texts are barely (or not at all) readable at 640x480. Damn ancient technology!

Re: Text size... I believe there's a rule that you have to use minimum font size 14pts for your text to be legible on standard definition displays.

It really only matters for game critical stuff

edit: btw, test on all resolutions. Seriously. The xbox will automagically letterbox anything that is not 1280x720 - so you want to make sure it does that, otherwise your scaling play area is pretty much pointless on the 360

mystran · Post by **mystran** » Fri Mar 15, 2013 4:07 am

Regarding vsync/input-lag: you can usually make that mostly disappear if you force a wait until the actual vsync. In DirectX9 (and probably XNA/DX10/DX11 too) you do this by using an event query on the Present() call, then polling until hardware reports it's presented. If you don't do that, the system is allowed to queue draws for the next frame before the previous is even on the screen yet, and you can sometimes run into multiple frames of "bogus" lag depending on what you draw. In OpenGL glFinish() is supposed to do the same thing.

The downside of such "hard sync" is that you will take some performance hit by reducing parallelism. The upside is that it makes games playable on vsync (and actually usually feel better than non vsync). You can also trade for a bit of lag vs. performance by only doing the sync (ie event query poll or glFinish()) just before you start drawing the next frame (this puts a "max one frame" cap on the lag).

DrInfy · Post by **DrInfy** » Fri Mar 15, 2013 7:43 am

mystran wrote:Regarding vsync/input-lag: you can usually make that mostly disappear if you force a wait until the actual vsync. In DirectX9 (and probably XNA/DX10/DX11 too) you do this by using an event query on the Present() call, then polling until hardware reports it's presented. If you don't do that, the system is allowed to queue draws for the next frame before the previous is even on the screen yet, and you can sometimes run into multiple frames of "bogus" lag depending on what you draw. In OpenGL glFinish() is supposed to do the same thing.

The downside of such "hard sync" is that you will take some performance hit by reducing parallelism. The upside is that it makes games playable on vsync (and actually usually feel better than non vsync). You can also trade for a bit of lag vs. performance by only doing the sync (ie event query poll or glFinish()) just before you start drawing the next frame (this puts a "max one frame" cap on the lag).

Thanks, I did not know that and it could even prove to be useful at some point. I was actually wondering how some games were able to do it, but never actually bothered to try to find out.

Indeed there's quite a bit of testing and tuning to be done before the Xbox version is ready, but that will have to wait until the deployment is done, which seems to be taking ages...

DrInfy · Post by **DrInfy** » Fri Mar 15, 2013 8:53 am

Uhm, riiiiiiiiiiight. Testing the Xbox version...

Loading screens take like forever or more. Main menu was running 10 fps on resolution 640x480.

Although when I finally got past the loading screens, I had 60 fps at the start of the stage 1, but the game didn't register input... :p

Solid start I'd say. This is going create one major headache.

nasty_wolverine · Post by **nasty_wolverine** » Fri Mar 15, 2013 5:19 pm

DrInfy wrote:
mystran wrote:Regarding vsync/input-lag: you can usually make that mostly disappear if you force a wait until the actual vsync. In DirectX9 (and probably XNA/DX10/DX11 too) you do this by using an event query on the Present() call, then polling until hardware reports it's presented. If you don't do that, the system is allowed to queue draws for the next frame before the previous is even on the screen yet, and you can sometimes run into multiple frames of "bogus" lag depending on what you draw. In OpenGL glFinish() is supposed to do the same thing.

The downside of such "hard sync" is that you will take some performance hit by reducing parallelism. The upside is that it makes games playable on vsync (and actually usually feel better than non vsync). You can also trade for a bit of lag vs. performance by only doing the sync (ie event query poll or glFinish()) just before you start drawing the next frame (this puts a "max one frame" cap on the lag).
Thanks, I did not know that and it could even prove to be useful at some point. I was actually wondering how some games were able to do it, but never actually bothered to try to find out.

Indeed there's quite a bit of testing and tuning to be done before the Xbox version is ready, but that will have to wait until the deployment is done, which seems to be taking ages...

Um, regarding vsync its not quite right what you say, it depends on driver implementations...
an application can only request for vsync to be on, but the card can decide not to turn it on.
to enable vsync, it has to be specifically in the driver (via control panel)... If your app assumes that vsync is on when its off, you ll have some crazy things on screen.

Best approach is your game update to be fixed at a certain FPS, and your render cycles to be completely independent (too high framerates will cause tearing though) and poll inputs in the game update cycle...

if you want i can post the main loop from what i am working on...

n0rtygames · Post by **n0rtygames** » Fri Mar 15, 2013 5:33 pm

DrInfy wrote:Uhm, riiiiiiiiiiight. Testing the Xbox version...

Loading screens take like forever or more.

My loading time in development is about 1m 30s. Compare that with the released version (Go check out the trial of Chronoblast to see) and it's a significant improvement.

Seek times are awful during dev, worse during peer review and usually blindingly fast when on the marketplace. However, it's advised that you don't rely on the marketplace magic.

Main menu was running 10 fps on resolution 640x480.

Like lightning!

Although when I finally got past the loading screens, I had 60 fps at the start of the stage 1, but the game didn't register input... :p

Impressive stuff. If you can maintain that 60fps - you've done very very well!

mystran · Post by **mystran** » Fri Mar 15, 2013 8:18 pm

nasty_wolverine wrote: Um, regarding vsync its not quite right what you say, it depends on driver implementations...
an application can only request for vsync to be on, but the card can decide not to turn it on.
to enable vsync, it has to be specifically in the driver (via control panel)... If your app assumes that vsync is on when its off, you ll have some crazy things on screen.

Well, yes, though generally drivers do default to "let application decide" (so it's mostly "advanced users" that will cause problems). But you're correct that it makes sense to handle the case where the driver doesn't sync (eg guard with a timer). Also in windowed mode (especially with Aero) I find that not syncing tends to give slightly better responsiveness. Anyway, just wanted to point out that the vsync -> queue growth -> lag issue is generally avoidable (can happen any time GPU lags CPU enough, but the artificial vsync-wait makes it most obvious).

Best approach is your game update to be fixed at a certain FPS, and your render cycles to be completely independent (too high framerates will cause tearing though) and poll inputs in the game update cycle...

My homegrown engine (original for 3D shooter proto, see http://www.youtube.com/watch?v=-5jc7uxwCmg, that project's shelved for too heavy art requirements) works "natively" this way (rendering in separate thread, with or without vsync), but it does make a shmup feel slightly loose to my taste, so I retro-fitted an option for regular frame-lock. The latter feels much tighter, but is also more sensitive to hickups (where as with the former you barely notice small framedrops). So it's a matter of taste really: do you want the tightest possible feel, or the smoothest possible experience (probably good idea if your render time varies a lot).

nasty_wolverine · Post by **nasty_wolverine** » Fri Mar 15, 2013 9:48 pm

mystran wrote: (rendering in separate thread, with or without vsync)

You dont need to multi thread a shmup, graphically shmups donot require such raw power, this raises a lot of sync issues too, just one thread is enough...
multithreading a shmup is like needing an extra arm just so you can wear two different watches with different time zone synced...

DrInfy · Post by **DrInfy** » Sat Mar 16, 2013 8:40 am

After a full day of testing stuff on my Xbox360 the game still runs at ~1 fps using XNA Game Studio Connect, but starting it from it's own game, allows the game to run at 60 fps even on 1080p, which is rather nice I must admit. However the bad news is that Garbage Collector hates me even more than I hate it and creates massive FPS drops, especially when there are a lot of rockets in the air and on stage 6 with CPU driven star particles. I haven't tried to optimize GC usage at all frankly because there has been no need for the PC version, but it seems all I have to do is to take out the trash and the game will run just fine on Xbox360.

On a special note about multithreading, I tried splitting some of my physics engine functionality to multiple threads and only ended up making the performance a LOT worse.

As to how calculating acceleration models can be slower on 8 threads compared to 1 is just weird and I guess it has something to do with OS (both Windows and Xbox360) not understanding how to split that workload to separate cores. I could probably fix that by assigning affinities manually, but it doesn't seem like there's any use for that after all.

Reiko · Post by **Reiko** » Sat Mar 16, 2013 1:21 pm

Just tried out the demo.

When I opened the game, I was glad that I could use my gamepad in menus (ps3 controller emulated as an x360 controller) without having to go out of my way to choose to use it.

The first thing I did was go to the graphics settings and turn on anti-aliasing, which was the only setting that wasn't maxed out. Then, I went to check out the tutorial. The text goes by pretty fast, so I couldn't really read it all properly. Fortunately for myself I already got the jist of the game from reading the posts in this thread, but yeah. Maybe slow it down a bit, or make it so you need to press a button to continue.

What threw me though is when the tutorial told me to dodge the bullets, I couldn't move and I died. As it turns out, I am supposed to use the keyboard to play the game. After retrying and using keyboard, the tutorial was okay. I might need to go through it again to give better feedback maybe.

Next thing I went to the controls and tried setting player 1 to use my gamepad, but the setting was stuck on Keyboard.

When I switched to the player 2 controls, I had some trouble with scrolling through the list using my gamepad (it would skip over things) but using the keyboard didn't have a problem. Actually, it seems to be a problem with using the analog stick, because using the D-pad didn't have any issue. I'm guessing I must have moved the stick slightly left or right and that was causing the cursor to skip around. Perhaps this could be fixed by using a small dead-zone for analog stick in menus?

I had the same issue with player 2 though, I couldn't change the setting off of Gamepad1. Btw, I have two of these PS3 controllers plugged in to my computer both set up as emulated X360 controllers, and both of them did work in the menus.

I also second the suggestion about using the fire button to select in menus. Once I got to the character select screen, I couldn't use my gamepad any more. I didn't realise I needed to press enter and actually just ended up clicking with the mouse to continue on.

Anyway so I gave up on that and decided to play the game just using the keyboard. The music and visuals are really good! The explosions are pretty satisfying, and the gameplay is fun too. I thought that the red marking showing incoming enemies was clever.

What I would recommend is if you can add some kind of audio feedback when you hit an enemy. It didn't really matter for the small enemies that die instantly, but for the bigger ones, and for the boss on the 3rd stage, it felt a bit weird to shoot at them for a while, but not hearing any sound when hitting them, even though I could see the white light.

As for the boss battle itself, I felt like there was something missing but I couldn't quite put my finger on it. Perhaps add more attacks, and make it switch between them more often. "Keeping the player on their toes", etc. That being said I was just playing on Easy so I'm not sure if higher difficulties are different.

The other thing that felt weird was when I held down shift for slow movement, there was no visual indication that I was in slow movement mode. But I think this is just because I'm used to playing exceed 3rd/stella vanity, and touhou has it too. Since I believe you said it was because the analog stick could be used for slower movement, then for this game I guess there doesn't really need to be a visual indication.

DrInfy · Post by **DrInfy** » Sun Mar 17, 2013 3:40 pm

Thank you Reiko, that feedback will prove valuable. Especially your feedback concerning the tutorial, as I was considering making it even faster.

The easy difficulty is actually balanced based on what my 10 year old relative can do in story mode, so it probably doesn't make any veteran shmup player too engaged even in arcade.

Still 3rd stage boss probably needs an extra pattern or two thrown to it. I've always saved my rockets at the end and just blasted through the rather long final pattern quickly so I never noticed that it is actually a bit too long. You are absolutely correct about the hit sound too and controls really should auto-select themselves correctly even when starting a game with a different one than selected in the options.

Now that the Steam release won't work itself out we're only going to have one more chance. The release version needs to be absolutely perfect and blow everyone out of their minds for both PC and Xbox. There's still a lot of work to be done until we're there.

Reiko · Post by **Reiko** » Mon Mar 18, 2013 9:27 am

Well, I'd be glad to give feedback on any future versions

Lord Satori · Post by **Lord Satori** » Tue Mar 19, 2013 5:29 am

why only xbox? is it really that hard to get games onto psn? just curious, xbox seems to have a much wider game selection, even though you have to pay for xbox live.

anyway, this game looks really cool, I might give it a try.

DrInfy · Post by **DrInfy** » Wed Mar 20, 2013 1:29 pm

Lord Satori wrote:why only xbox? is it really that hard to get games onto psn? just curious, xbox seems to have a much wider game selection, even though you have to pay for xbox live.

anyway, this game looks really cool, I might give it a try.

There's no way we could afford a real development kit for any console. Besides I'm the one doing most of the heavy coding work and I really can't program at all in C/C++. I've used managed languages (Visual basic, Java & C#) ever since I was 10 years old and I'd say that I'm rather effective with them. There is no working C# solution for PS3 as far as I know and I think I can get the game just barely running on Xbox360 at playable frame rates. It might be possible to port the game to Linux and mac using Monogame and perhaps even Ouya. Anything else is pretty much a no-go, I think.

shmups.system11.org

Saviors - Released in Steam and v1.5

Saviors - Released in Steam and v1.5

Re: Vote for Saviors in greenlight or give feedback

Re: Vote for Saviors in greenlight or give feedback

Re: Vote for Saviors in greenlight or give feedback

Re: Vote for Saviors in greenlight or give feedback

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up

Re: Saviors - A game about blowing things up