9001

sub

Active Member
πŸ’» Oldtimer
Discord Member
Joined
Jun 18, 2003
Messages
5,952
Best answers
0
KYnetiK said:
Regarding those sorts of transition scenes, I've found it more helpful to put them in as early as possible - even as placeholders - than try to supplant them in later. They can also be useful for a buffer period for certain things to initialise, or as a general system that can be applied to other objects and make them function easier. And sometimes the proto 'art' can often be more instructive symbolically and define the overall artistic character moving forward - for example with The Gauntlet the proto backgrounds became the plot setting, as more detail meant sacrificing speed, vision/contrast, and overall reliability.
I think that's good advice. The sooner you can get placeholder assets in the better. Even just getting a gamestate for all contexts the game can be in, and transitions to / out of has been helpful in terms of defining a scope. ie: A main menu state, options, level selection, etc.

KYnetiK said:
I'm actually curious how 9001 handles attack cooloffs and wall/surface collisions. Cant quite tell if melee is always a swooping attack or if there is a standing melee also? How would it handle both players using standing/low speed melee against each other at once. Also, no teleport?
There is no actual swoop button or anything. If the player presses a direction, force is applied and you'll move in that direction. There is always a small amount of drag and gravity acting on you, so you'll gradually lose momentum / fall to the ground. It's a bit like ZBall in that respect.

Melee collisions occur whenever two players collide. You don't even need to hold down a melee button or have a melee attack selected. The same code that determines who wins at high velocities determines the winner at low velocities. If there is a tie as both players hit head on with the same speed, then both get damaged and knocked back.

There is teleport, though it's a bit hard to see the teleport fx with everything that I've added since. Both me and the AI teleport a few times in the first video. In the second video only I teleport, I accidentally broke the ability for the AI to teleport and did not realize it when recording. You can actually hear the teleport sound spammed a bunch in the second video -- The AI wants to and is trying to teleport but couldn't.

For attack cooloffs there is two types, I guess. Melee and Energy attacks. Energy attacks are still up in the air, but I'll have a cooldown of some sort for sure.

For melee, it does two things. 1) After a melee collision, both players are immune to melee hits from others for a brief period of time. Off the top of my head it is probably on the order of 500 ms but I could be wrong. This means that if you hit someone, a third player can't swoop in and get a free hit due to your temporary immobility. They'll just fly right through you.

The other thing I did for melee is implement a combo system, though it works a bit differently from ESF. Every time you hit your enemy the combo count increases. Combo count gets reset to 0 if they are not hit immediately after recovering from being hit. The max allowed number of combos is 2.

So in other words, you can hit them, hit them again immediately after being hit, but then you need to back off. If you go for the third hit immediately after they recover, they will automatically win the collision. You need to give them a couple of frames before going in for another hit. This is necessary because tempo is extremely easy to abuse here. You can spiral one hit into the enemy having no chance to recover. Moreover, your opponent would be able to do the same to you. It wasn't fun. So the AI knows this and will back off for a second after it scores 2 hits. A lot of the motivation here is everyone who has played ESF for a while has experience with someone using the ceiling / ground exploit on them to get an infinite number of hits. In ESF you can actually block that with another exploit (holding b / the use button down), but that just increases the amount of time your exposed to beams....

For terrain collisions, I'm not really sure what you want to know. I'm not sure how to explain it well but the aura effect that you see and the terrain are part of the same system. They're essentially a giant grid of ragdolls. So a grid of point masses, each point connected to their neighbor to their right and below. A point can either be terrain or air (or energy, but that's still WIP). Air points are attracted to players, and I'm drawing quads / triangles between the points with a bit of transparency. So when the points overlap, you get that aura effect naturally.

Terrain points aren't affected by the movement of air, and some different physics rules get applied. So yeah, the terrain is essentially a ragdoll which gets force applied to it when contact occurs between a player and a some point along a terrain edge. If a terrain point moves far enough onto a neighbors position, it can actually 'jump' and either occupy a new grid position if that point was previously air, or two terrain points can occupy the same position. It's a bit like a fluid simulation in that respect. Here's a screenshot from a build when the terrain system was being worked on, you can see what I'm talking about a bit better hopefully.


I am planning on adding a flag which gets set when you are on terrain, which kind of soft locks you to the terrain and uses reverse kinematics to glue / animate your guy to the ground. You probably won't be able to walk, so any movement will launch you into a swoop again. I've tried implementing this 3 different times in the past and failed each time. Eventually I'll figure it out. I think my math on detecting the point of collision with the terrain might have been wrong due to the terrain also moving, especially when contacted by the player.

Sorry for the very long explanation for what was 4 sentences

-------------------------

I wasn't even aware there was a switch in the workflow from the earlier versions of flash. I have a constant nagging desire to ditch everything I've built and go off and use Unity or Unreal 4 or Godot engine or whatever, but that's the type of thing which stops me. At least with what I have now I understand everything about the codebase, and I have access to all of the code so I can fix any problem I encounter. The rug isn't going to be pulled up from under me with a big product update that changes my workflow on something I liked. It's still tempting though.

I don't know that the distinction between scripting and programming is all that useful. In my mind they're close enough as to be considered all the same shit. I've no doubt you'd be able to work in whatever language you wanted to if you spent some time at it. Honestly, if anything I'd argue scripting is harder.

You don't need to compile your code with a scripting language, which is nice but you pay for with a performance impact. How much extra effort is required to make your code run at a reasonable speed?

You usually don't need to specify types, but this comes at a cost to readability later down the line. There's something to be said for explicit interfaces where you know for sure that you're giving it proper information, and you're explicitly told before even trying the code that it is wrong. Not having explicit types makes refactoring your code harder. I can confidently rename any variable and know that my IDE will correctly rename all instances of said variable. With a scripting language, not so much. You have to examine each and every instance to make sure it's actually the variable you want to rename. That's just one example.

When I was working with Javascript every day for work, I had come to think of it as "javascript doesn't care". Want to give a string to a function which needs an int? Javascript doesn't care, it'll run. Typo somewhere? Javascript doesn't care, it'll run. Want to not use semicolons? Javascript doesn't care. Want to use semicolons? That's fine too... I find the whole thing kind of insane.

The downside to flash nowadays is that the web doesn't support it anymore, though I guess you could bundle a flash player and have people download an exe. The Haxe language might be worth looking into honestly. It's supposedly designed with actionscript in mind, and it compiles to an absurd number of other languages, so you'd probably be able to compile a version of whatever you're making to run on the web.

I think this reply is way too long so I'm going to stop now.
 
Last edited:
Misanthropist
🌈 Beta Tester
πŸ’» Oldtimer
β˜… Black Lounger β˜…
βœ”οΈ HL Verified
πŸš‚ Steam Linked
Discord Member
Joined
Sep 18, 2003
Messages
1,370
Best answers
1
For terrain collisions, I'm not really sure what you want to know.
I was actually referring to how you dealt with attack cooloff regarding wall collisions, you did cover that but I really appreciate you detailing how the environment operates. It gives me interesting ideas, and I admire you got it functioning so.

I am planning on adding a flag which gets set when you are on terrain, which kind of soft locks you to the terrain and uses reverse kinematics to glue / animate your guy to the ground. You probably won't be able to walk, so any movement will launch you into a swoop again. I've tried implementing this 3 different times in the past and failed each time. Eventually I'll figure it out. I think my math on detecting the point of collision with the terrain might have been wrong due to the terrain also moving, especially when contacted by the player.
This is a pretty frustrating thing to get right especially with uneven dynamic terrain. Keep at it though. Sometimes its as simple as flagging the collision, maybe doing a radial raycast approach to continue checking for collision, setting the player position accordingly, and only relinquishing this process (!collision) once player is too far away from geometry. Ive been trying to recreate the pixel perfect dynamic collisions that revolutionised Flash (and led to things like Box2D and Angry Birds/physics based games etc), and this is an interesting puzzle if I dare say.

I wasn't even aware there was a switch in the workflow from the earlier versions of flash. I have a constant nagging desire to ditch everything I've built and go off and use Unity or Unreal 4 or Godot engine or whatever, but that's the type of thing which stops me. At least with what I have now I understand everything about the codebase, and I have access to all of the code so I can fix any problem I encounter. The rug isn't going to be pulled up from under me with a big product update that changes my workflow on something I liked. It's still tempting though.
I like to think that what gives the user optimum control is naturally the best method for that user. There are nuances to this sure, but often what we know best gives us more creative control in a given timeframe, despite any inherent tedium. Regardless of syntax, there will still be times where debugging means finding that one extraneous/ missing brace or underscore XD I will look into Haxe and see how it fares for me.
 

sub

Active Member
πŸ’» Oldtimer
Discord Member
Joined
Jun 18, 2003
Messages
5,952
Best answers
0

There's a gallery in there of possible header images to use for steam (it's that small image which appears to the right of the videos / screenshots). I guess my question is do any of these work or could they work with some tweaking, or should I do something else for that? I should add that if i decide to use one of those images i'd actually go through the effort of centering or aligning the text better
 
Misanthropist
🌈 Beta Tester
πŸ’» Oldtimer
β˜… Black Lounger β˜…
βœ”οΈ HL Verified
πŸš‚ Steam Linked
Discord Member
Joined
Sep 18, 2003
Messages
1,370
Best answers
1
I like #4 and #6
 

sub

Active Member
πŸ’» Oldtimer
Discord Member
Joined
Jun 18, 2003
Messages
5,952
Best answers
0

sub

Active Member
πŸ’» Oldtimer
Discord Member
Joined
Jun 18, 2003
Messages
5,952
Best answers
0
For now I've just made it #4. #6 has a small part of the GUI showing which I'd have to edit out. If anyone likes another one better or thinks I should do something different, please let me know. Also let me know if you think they all suck ;)

Screenshot from 2020-01-17 22-58-55.png
 

sub

Active Member
πŸ’» Oldtimer
Discord Member
Joined
Jun 18, 2003
Messages
5,952
Best answers
0
Recorded another video. Still no energy attack system but an initial version of the galaxy meta-game surrounding the combat is almost done (not shown here though).

 
Misanthropist
🌈 Beta Tester
πŸ’» Oldtimer
β˜… Black Lounger β˜…
βœ”οΈ HL Verified
πŸš‚ Steam Linked
Discord Member
Joined
Sep 18, 2003
Messages
1,370
Best answers
1
Watching the world geometry 'find' its new shape makes it look alive, almost creepy XD
 

sub

Active Member
πŸ’» Oldtimer
Discord Member
Joined
Jun 18, 2003
Messages
5,952
Best answers
0
I've wondered if I should try to make it look more natural. It could definitely be tweaked to remove the creepiness, but I don't think it'd be straightforward to do.
 
Misanthropist
🌈 Beta Tester
πŸ’» Oldtimer
β˜… Black Lounger β˜…
βœ”οΈ HL Verified
πŸš‚ Steam Linked
Discord Member
Joined
Sep 18, 2003
Messages
1,370
Best answers
1
Initially I would have considered making the terrain a net of nodes/collision points (that would each connect to their neighbours for graphical reasons), and when a player touched one, you would apply an inverse velocity to the player, destroy that node, then redraw their connections. (though always getting the 'correct' border outline would be annoying I would imagine)

However this would take an enormous number of nodes to look right, and affect performance. I am assuming this is why you went for an IK fluid approach? The player is essentially pushing the terrain nodes into new positions yes? Giving the nodes velocities can often open a can of worms. Am a bit curious how the connections are recalculated and drawn or not, especially with how you break off fragments in places.
 

sub

Active Member
πŸ’» Oldtimer
Discord Member
Joined
Jun 18, 2003
Messages
5,952
Best answers
0
I'm not entirely sure we're on the same page. It sounds like the first paragraph is how it already works unless I'm misunderstanding.

The terrain nodes have their own velocity, which is effected by their connection to neighboring terrain nodes (if a neighbor node is moved to the left, it drags all connected nodes), and the player impacting a terrain node (terrain gets velocity in the direction the player was traveling, with the player getting their velocity adjusted + depending on their velocity on impact a boost in velocity to simulate a jumping-like effect).

The entire thing is essentially a grid of nodes, with Terrain nodes able to jump to new positions on the grid if they move far enough away from their current location. If they don't travel far enough to jump to a new node they'll eventually be dragged back towards a resting position because they're dragged by connections with their neighboring terrain points. This jumping and dragging back is where the effect that we're talking about comes from. Also, I don't have an explicit list which tracks which points are explicitly connected because keeping track of that was worse for performance and unnecessary. Every connection is implied.

On each frame I'm throwing away the world mesh and generating a new one. Determining the triangles to draw is done by iterating over nodes on the grid (in view) and looking at a given nodes neighboring nodes. So for every node we're drawing two triangles (forming a quad) with the points to its top, topleft, and left. If a node is terrain, it figures out if the quad is split diagonally bottomleft to topright, or topleft to bottomright.

So for example, if a node is terrain, and its neighbor to the top is terrain, and its neighbor to the left is terrain, and its neighbor to the topleft is air, it's a quad split diagonally bottomleft to topright. So it draws a triangle with the air draw properties between the nodes of the topleft, left, and top. It then draws a triangle with the relevant terrain properties between the left, top, and the cell that we're at for iteration (the bottomright).

So at the moment I mostly don't keep track or care about the boards previous state, except in that I interpolate a points position from its previous to its current. It's one of the last things on my todo list but eventually I need to add a supplementary system to this which keeps track of when a terrain node is destroyed, and add the transition-like effect to its next most relevant position, which is what I think you're advocating for?

This is all very confusing, I'm sorry lol.
 
Misanthropist
🌈 Beta Tester
πŸ’» Oldtimer
β˜… Black Lounger β˜…
βœ”οΈ HL Verified
πŸš‚ Steam Linked
Discord Member
Joined
Sep 18, 2003
Messages
1,370
Best answers
1
My first paragraph is saying that a node would never move - if it collide with players bounding box, then it applies velocity to the player and destroys itself. Your method has the nodes get pushed around by the player - they dont seem to get destroyed, only shifted to new places ie squished together or stretched apart, and become void if they have no neighbours?

The method of drawing quads is very interesting to me, thanks for the insight.
 

sub

Active Member
πŸ’» Oldtimer
Discord Member
Joined
Jun 18, 2003
Messages
5,952
Best answers
0
Ah, I see. Yeah, nodes mostly get shifted to new positions. It can stack more than 1 terrain on a single node, though I think I have it capped so there is some destruction. If a terrain node is by itself it just keeps moving on with whatever velocity it has until it hits into another terrain node.

There is another form of destruction too. I used to have the problem of the player clipping through terrain, because I wrote the physics system myself and I am an idiot. There was some edge case where I guess the player could slip through at a certain angle without the line-circle collision detection that I'm using for the player kicking in. I tried to solve this by looking for faults in the math but couldn't figure out what was going wrong. It wasn't a tunneling issue, that should have been covered. Eventually on a whim I said fu ck it (i refuse to be censored, Sky) and tried out checking the nearest node to the player. If it's terrain, and if it's not a collision terrain node (a node at the edge), I just destroy that node and all of its neighboring terrain nodes. So if you're moving too fast when you hit the terrain you can destroy it. It's one of those things that is clearly a bug in that it's not how it --should-- work, but it feels good to me so it's in.
 

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Top