- Jun 18, 2003
- Best answers
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: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.
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.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?
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.
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.