unfa / fps_v1 Goto Github PK

"FPS" is not a very catchy name to have...

Once the plot is sufficiently developed I guess I should rename the repository to something more meaningful.

Random idea of the day:

"Starbleed" (EDIT: there's an indie game studio with that name already: https://twitter.com/Raven_Burns_ )

The idea is to create a hitscan insta-kill continuous-fire super-weapon.

In death match it should probably respawn in 120 seconds. And picked up it should have 1 ammo cell loaded.

Once fired, the weapon would emit a narrow laser beam for 1 second straight, killing everything that it touches (basically doing like 500 damage per frame - so 30000 damage per second). It should also go through any enemy and damage multiple units in a row - so human shields won't work.

It'd be best used against large groups of enemies. Then you could cut down a lot of them at once with a single swing of the laser beam.

Visually I imagine the weapon to fire a simple glowing white beam of light.

The idea for this weapon comes from a dream I had, where I first have cut down a large distant pylon with it, and later I was running away to not get hit by this. I remember the fear that I can loose a limb or just be cut in half any second with this.

I guess the dream itself was based on my experience working with laser marking systems at work. The laser emitters don't seem to be making much noise when emitting laser - only the cooling is audible, but whatever the laser touches just sounds like a white-hot frying pan meeting your face.

I guess this could be reflected in the game - the firing sound could be suspiciously quiet, but the hit sound would be very loud in comparison.

For extra effect player models could be cut in half when hit with this, but I have no idea how to implement something like this, and it's not a huge priority. We could just go for instagib instead. I guess it'd be pretty realistic, when you deliver so much energy into human body - it's basically going to evaporate all the water instantly, leading to a steamy meat explosion. Like light sabers with Kyle Hill.

I think such a thrill or seeing and wielding this deadly beam would be a lot of fun in the game, but for the sake of balance it has to be rarely available. If it was to be a regular weapon like UT 2k4's Link Gun - it's have to be nerfed, and the insane damage is what makes it so exciting.

I was also thinking about maybe making it have 10 ammo cells, each firing the laser for 0.1 seconds, so you can fire it one by one, taking down 10 enemies (if you can aim it perfectly) or shoot it all at once on a group - this would have to be play-tested, maybe it'd make sense, maybe it'd make everyone just go for single shots and rthat'd remove the aspect of swinging the weapon from the game, and I think it'd be particularly frighting to look at, so it'd be cool to make players want to use that.

The gun could also have two modes - like 3 distinct shots vs -second welder.

In single player - cells for this gun could be dropped occasionally to make the player be able to defend against a larger group of enemies, or some extremely though enemies.

Maybe oversampled raycasting should be used to catch all hits for fast swings. I guess the gun could store it's location and rotation for the last and actual frame - and for big changes between the two it could perform multiple raycasts on distance intervals to accurately deal the insane damage per second.

I guess it's because the movement vector is applied locally, without taking Player rotation into account.

This should be decoupled.

Becaue the movement vector is (1,1,0) instead of (0,1,0) or so the movement is faster if the player is walking and strafing at the same time.

Could be exploited by speedrunners.

I think the proper way is to define a walk direction vector (this would also fix the problem where pressing 'a' and 'd' doesn't result in the player standing still.

Then te resulting vector should be normalized and multiplied by the walk_speed variable.

Turns out Player's Y velocity was not 0 when walking on the ground.

Combustible Lemonade fixed it!

Hmm, for some reason the hit_force variable in Gun.gd seems to have no effect on teh actual force applied to shot objects. Very strange.

Some resources:

https://www.youtube.com/watch?v=Ty4wZL7pDME
https://github.com/GDquest/Godot-engine-tutorial-demos/tree/master/2018/04-24-finite-state-machine

The main drive of the plot is the attack of alien forces on the human colony, who were present on the planet before humans reached it, but remained stealth.

Here's some ideas on how that could be maintained:

https://worldbuilding.stackexchange.com/questions/118607/

Instead of typical "explosive barrels" there could be gas tanks around the levels.

There could be a few different ones (in different colors) contrasting different liquid gases - nitrogen (freezing nearby enemies), oxygen ( melting surroundings and closer enemies), butane (exploding), or other.

It'd make sense for a research / observation facility on a distant planet. Barrels might also fit some areas.

There could be also fire extinguishers hanging around - when shot they could work as a smoke grande and extinguish any nearby fire. Might be useful for removing for damage from player. However at close range the shrapnel from the pressurized container would be really deadly.

I am thinking how the networking could work in this game - I have no deeper idea how it's implemented in most games.

I guess it'd need to send player's transform and velocity in the current map as well as he's actions via UDP all the time. In case some packets are lost - the game could use the transform/velocity information to sync clients back together.

I imagine the clients would then have all the basic logic for all players executed locally (omitting some unneed stuff like HUD and such).

I guess a server would initially just recieve and send the packets to everyone constantly.

Does this make sense?

Figure out how to model in Blender and import to Godot.

The bullet would push the object in the direction it was headed towards, maybe deflecting a little bit, but certainly not pushing with the collision normal.

Or would it?

To define a coherent artistic direction and make something more than just a random set of things, the project needs a story.

It might never be told in the game (it's the best if players discover it on their own as they go, right?) but it will define the frame for designing levels, enemies, weapons - everything.

A story will tie it all together - otherwise we'll just end up with a bunch of random assets put together that feel like a frankenstein's monster.

Needs research.

Some interesting pieces on QUake and QUake 2 movement.
The player says Quake 2 has almost no air control, also some stuff about jumping.
https://youtu.be/zj-jKn_e0k0?t=2m55s

Add items that give player ammo, and make him loose ammo when shooting.

The pickups could also respawn periodically for multiplayer.

After merging the healthbar and damage commit, walking is broken in Player.gd

Somehow the if health > 0: statements made the whole thing work very strange.

Maybe it has something to do with the fact that I moved the jumping logic before the gravity logic - and before it was after?