I’ve been working on an in-browser retro shooter, along the lines of Doom, and have an early playable demo using some Doom assets. The demo is an infinite level built from procedurally-generated rooms. Let me know what you think!
It’s called Vominate and it’s deployed to netlify:
Wow, you had me at endless procedural generation
Doom with physics is a welcome and nifty addition too.
I noticed you added Y axis mouse controls which I found a little unwieldy as everything on the original doom is on the same ground level. Might be unnecessary unless you’re adding platforms of different height. Just a thought for the final version.
Thanks. Good point I hadn’t thought of, about the Y-axis movement. Right now the only thing to look up at and interact with is some of the taller stacks of boxes, but the rooms might change in the future to be more quake-like than doom-like, with catwalks/ramps or other kinds of height transitions. Maybe for now I should disable or tone down the sensitivity of y-look…
hi @pepperinmyteeth : First, I’d like to compliment you on a job very well done! Keep up the excellent work! Secondly, I’d like to ask, if possible, could you release the part of the code that has sliding collision when walking up against a wall or object? Once again, keep up the great work!
Hey @Aerion thanks for the kind words. The sliding collisions is actually handled by the physics engine (Physijs, https://chandlerprall.github.io/Physijs/), so the really interesting code is all in there.
To get the physics engine to simulate nice-feeling player movement, I basically attached the camera to a capsule shape (Physijs.CapsuleMesh) and then disabled rotation for that shape: playerObject.setAngularFactor(new THREE.Vector3( 0, 0, 0 ))
… and then rotated the attached camera, for mouse-look
Here are some of the parameters that I’m using, as far as tuning:
Floor and wall friction: 1.0
Floor and wall restitution: 0.5
Player friction: 1.0
Player restitution: 0.0
Player mass: 3.0
Player shape’s height: 4.5
Player shape’s end cap radius: 1.25
Simulation gravity: (0, -30.0, 0)
And last, I use a central impulse (playerObject.applyCentralImpulse()) on each frame, to push the player around. The impulse is vector scaled to length 3.0.
Hopefully that helps!
Really retro! I played with a touchpad, and it sort of worked. I experienced many times that holding W/S before touching would not enable rotation, whereas touch before W/S would always work. A/D doesn’t seem to have the same issue…?
Also, I would appreciate if keyboard and mouse controls were equivalent. Now AD turns in keyboard mode and “sidesteps” in mouse mode. Keyboard mode is really hard to play, because there is no sidestepping, so you need to first run into the line of fire, then turn, then return fire…
Hey, thanks for the feedback. Very weird about the trackpad’s interacting with W/S vs. A/D. I’ll try to reproduce the problem myself.
You make a good point about the keyboard controls, which I mapped pretty haphazardly. I think it’d be a lot better if it were actual arrow keys for movement, and alt as the modifier for strafe. That’s sort of the de facto standard I think?
@pepperinmyteeth : Not really. W/A/S/D / Arrow keys is the standard. Use threex.keyboardstate.js & stemkoski’s KeyboardState ( if you want to detect key down / key pressed / key up )