The game could use a Game Over screen and way to restart (without reloading the page) on death. Otherwise, it appears that the core mechanics are well executed, and a bit more length and variation could only help.
I agree the name is risky. It was actually a funny phrase that occurred to me when I started work on the game. Later, when I started talking about it to my friends, I said it was only the working title, but lots of people said I should keep it, so I did.
Yes, I agree it needs a game over screen and a way to restart without reloading. These are both high up the list. The reason they are not there yet is that I think of the game as a sandbox at the moment.
Use Google Chrome to play the game. I've been working on this in my spare time for the last few months. This is an alpha version. The development has been iterative: adding something, trying it out, then often removing it. The gameplay is evolving into something that is centred around a series of tactical, pitched battles.
I'm simply posting this to show off what I've been working on. I would greatly appreciate suggestions for improvement. I know the graphics are horrible.
I think you're right that it would have been quicker in Flash. The engine I used is mostly a drawing engine, with some basic game stuff included (particles, the beginnings of collision detection). However, this project was all about learning Javascript, and working in a newish field. Plus, a lot of the time I spent was on graphics (I suck at drawing) and iterating and exploring to find the gameplay and style.
Once you learn someone else's framework (not much of an option yet) or build your own (as I and others have) it takes no longer to make games in JS than Flash.
What does Flash provide that makes it easier to develop games like this? If Flash is currently much better than Javascript, don't we just need better high level canvas graphics libraries?
Graphics: The character's movement animations are smooth and cohesive; the characters do not appear to jump from animation to animation.
Gameplay: Guns: The three available guns are nice, but I want that mortar launcher.
Gameplay: Shooting: The ability to shoot multiple bullets and create alternative directions because of kickback is a neat feature.
Gameplay: Opponents Shooting: The infinite amount of bullets that the opponent has does not jive with my predicament. The shotgunner lays down a full spread of bullets while the mortar shoot covers from a distance. My theory was to wait for the opponent shotgun guy to run out of bullets.
Gameplay: MortarDude/Cover: The first mortardude fires directly onto a canopy, sometimes the mortar hits the canopy and explodes, other times when the trajectory puts the mortar on path to hit the canopy, the mortar falls through.
Gameplay: Damage: No clear sign that I was hurt by that last bullet that was shot at me while I was diving behind the tires. If you want to leave off a damage bar, take off body parts from the character accordingly.
The player will get the mortar launcher - still figuring out how to make the controls work.
I hadn't thought of giving the enemies limited ammo. I will try it and see how it feels. I haven't done any work on what weapons the player gets and when. This will come once I start making more levels.
Yes, a damage bar seems like a good intermediary step while I explore other options for showing bullet hits.
Using "Z" as a key makes it really hard for Germans to play the game since for us, y and z are switched on the keyboard.
Using x,c,v or 1,2,3 would be better in this case :)
It's tough to use the arrow keys for JavaScript games. If you bind events to those keys, the web browser won't care and still use those keys to scroll. It's bad design since then you'll be scrolling and manipulating the game at the same time.
The reason that this isn't a problem for Flash is because Flash grabs and steals all keyboard and mouse focus away from the browser; not something anyone should re-implement in JavaScript.
Thanks for the tip. I should have noticed this myself, as I live in Berlin (but have my keyboard set to English). Will be changing the controls to try and support Dvorak, Qwerty and Germans.
Seriously, if you haven't done it already, find or make yourself a module that lets the user customize the keyboard controls to his/her preference. Then you can just drop it into any game you write, and presto! You're good to go!
For even more gooey goodness, make up some one-click "profiles" for different keyboards that users can pick at a click. You don't need to make it top priority, and you may not even need to do all the work yourself. If you just ask for people's preferences in a forum, or a feedback form with the game itself, you can probably get a ton of helpful input.
Always good to see a Javascript game like this (i.e. not sudoku / tic-tac-toe). It's good. I did notice some weird stuff with grenades disappearing through the floor though.
It looks like it takes awhile -- like at least several seconds -- for the game to pick up my 'z' to start keypress. Then, the playfield goes blank, and stays that way for at least a minute or three (I'm still waiting for something to show up). That may just be Firefox, but I'm not going to install a new browser just to play one game.
That said, I noticed your loading bar reports xx of yy as it progresses, with BOTH values increasing. The 'of' value (yy) is traditionally fixed at the final value xx should reach, in order to give the user some sense of actual progress. I would recommend following that practice, if at all possible.
What about making this multiplayer? A player starts this up and is placed immediately into a battle with another random player? Maybe a few NPCs in there for fun.
Nice idea. However, I am aiming to make a game about beating a system, rather than out-thinking someone else. The idea is to present the player with set-pieces - mostly pitched battles - that involve a few NPCs that behave in a predictable manner. Thus, the player must figure out how to solve tactical problems.
I'm considering doing an unrealistic Halo-like health system. That is, if you take too much damage too quickly, you die, but your health recharges when you're not getting hit. I think this allows set pieces - "I've got these resources to get through this section" - which is exactly what I'm trying for in Pistol Slut.
I actually liked the riskiness and uncertainty of not having a health counter and not being sure if the next bullet would be the one that takes you down.
Maybe with a stronger indication of when you get hit it could work quite well without one.
It's quite a can of worms - there are many different keyboard layouts in common use (QEWRTZ, AZERTY, etc).
If you can find a way to make it work using only layout-independent keys (arrow keys, ctrl, alt, enter, space, esc, etc) you will save yourself a lot of headaches.
The game could use a Game Over screen and way to restart (without reloading the page) on death. Otherwise, it appears that the core mechanics are well executed, and a bit more length and variation could only help.