Pistol Slut, a 2D shoot-em-up platformer in Javascript(pistolslut.com)
pistolslut.com
Pistol Slut, a 2D shoot-em-up platformer in Javascript
http://pistolslut.com
61 comments
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.
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.
[deleted]
I agree. I would not excited about visiting this domain while at work.
You shouldn't be playing shooters at work ;)
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'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.
Any reason it doesn't work in other browsers?
Actually, the graphics is good. Loved the stick figures.
I second that. The graphics are very stark and minimal, which really gets the player into what's important. I would say don't change the graphics.
Also, I really like how the bullets don't always aim straight. It's a cool bit of realism.
Also, I really like how the bullets don't always aim straight. It's a cool bit of realism.
Thank you. I wish I was a better animater and drawer.
This was fun, but doesn't this prove how poorly built Javascript is for games? Months to develop something that could be done in Flash in a few days.
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.
All it proves is that the Flash toolchain is more mature.
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?
[deleted]
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.
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.
Thanks very much for your detailed feedback.
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.
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.
Just make the enemies spend 2-3 seconds reloading after they've fired a certain number of shots.
They do already, but I could lengthen the reload time.
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 :)
Other than this: fun game
Other than this: fun game
As a Dvorak user, all of these JS games with their hardcoded keys are impossible to play without changing my layout back to Qwerty.
1,2,3 + arrow keys would be a better choice for sure.
1,2,3 + arrow keys would be a better choice for sure.
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.
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.
Yup! I do most of my browsing with keys, and I can't tell you how many times I have hit CTRL+W repeatedly before realizing flash had the focus. Eww.
What ever happened to standard mapping of ctrl, alt, space, shift for arcade games on PC?
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.
Just don't hardcode.
^^^THIS!^^^
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.
Best of luck!
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.
Best of luck!
Equally unworkable with french (AZERTY) keyboards.
asdw would be better for qwerty anyways.
It's a testament to the reach of JavaScriipt that this even runs on the Kindle I'm browsing on (slowly).
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.
I like the stick figures also!
I like the stick figures also!
Thanks a lot. Yes: collision detection is flaky after some recent changes. Going to work on it.
Just played a similar game today also in javascript/html5: http://www.phoboslab.org/biolab/
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.
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.
The game loading and then going blank is something I've seen and fixed in Safari, but not Firefox. What version of Firefox are you using?
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.
Nice. Would like to see a health counter. I can't see a way to restart other than by refreshing the browser.
Yes, both good points - thanks.
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'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.
Maybe with a stronger indication of when you get hit it could work quite well without one.
Yes, maybe bullet hits could send the player/enemies into a stagger as well as causing the existing blood spurt?
My keyboard is set to Dvorak, the controls are quite difficult for me.
That is very useful - thanks a lot. I will try and find a set of keys that work well with both Qwerty and Dvorak.
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.
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.
That's a good idea. Thanks.
Better to provide an options screen to let people choose the keys they want to use.
I would prefer to find a set of keys that work for most people. An options screen sounds too heavyweight for a web game.
It's very slow for me. And when I hit the keyboard buttons my browser brings up the search page prompt.
(I'm on Firefox, Ubuntu)
(I'm on Firefox, Ubuntu)
The controls are really sluggish. Is that from the game or the underlying tech?
Sluggish in what way?
nice! I love the stick figures and the simplicity of the game.
Thanks a lot. I've tried to keep everything minimal.
stop reinventing the square wheel, please.
i don't want to play a game that looks like it's from 20 years ago, the only difference being it runs EVEN WORSE than it did on a 486.
i don't want to play a game that looks like it's from 20 years ago, the only difference being it runs EVEN WORSE than it did on a 486.
There's a lot of JavaScript games out there. The fact this is a game - written in JavaScript - is no-longer newsworthy.
It's definitely news-worthy. I love seeing things that people have been working on no matter what they are.
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.