9001

sub

Active Member
πŸ’» Oldtimer
Joined
Jun 18, 2003
Messages
5,961
Best answers
0
Location
New York
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
🌠 Staff
🌈 Beta Tester
β˜… Black Lounger β˜…
βœ”οΈ HL Verified
πŸš‚ Steam Linked
πŸ’» Oldtimer
Joined
Sep 18, 2003
Messages
1,406
Best answers
1
Location
Perth, Australia
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
Joined
Jun 18, 2003
Messages
5,961
Best answers
0
Location
New York

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
🌠 Staff
🌈 Beta Tester
β˜… Black Lounger β˜…
βœ”οΈ HL Verified
πŸš‚ Steam Linked
πŸ’» Oldtimer
Joined
Sep 18, 2003
Messages
1,406
Best answers
1
Location
Perth, Australia
I like #4 and #6
 

sub

Active Member
πŸ’» Oldtimer
Joined
Jun 18, 2003
Messages
5,961
Best answers
0
Location
New York
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
Joined
Jun 18, 2003
Messages
5,961
Best answers
0
Location
New York
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
🌠 Staff
🌈 Beta Tester
β˜… Black Lounger β˜…
βœ”οΈ HL Verified
πŸš‚ Steam Linked
πŸ’» Oldtimer
Joined
Sep 18, 2003
Messages
1,406
Best answers
1
Location
Perth, Australia
Watching the world geometry 'find' its new shape makes it look alive, almost creepy XD
 

sub

Active Member
πŸ’» Oldtimer
Joined
Jun 18, 2003
Messages
5,961
Best answers
0
Location
New York
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
🌠 Staff
🌈 Beta Tester
β˜… Black Lounger β˜…
βœ”οΈ HL Verified
πŸš‚ Steam Linked
πŸ’» Oldtimer
Joined
Sep 18, 2003
Messages
1,406
Best answers
1
Location
Perth, Australia
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
Joined
Jun 18, 2003
Messages
5,961
Best answers
0
Location
New York
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
🌠 Staff
🌈 Beta Tester
β˜… Black Lounger β˜…
βœ”οΈ HL Verified
πŸš‚ Steam Linked
πŸ’» Oldtimer
Joined
Sep 18, 2003
Messages
1,406
Best answers
1
Location
Perth, Australia
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
Joined
Jun 18, 2003
Messages
5,961
Best answers
0
Location
New York
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.
 

sub

Active Member
πŸ’» Oldtimer
Joined
Jun 18, 2003
Messages
5,961
Best answers
0
Location
New York
It still needs a lot more work, but I got around to making a Steam page for this.

 
Base belongs to me.
πŸ‘‘ Administrator
🌠 Staff
βœ”οΈ HL Verified
πŸš‚ Steam Linked
πŸ’ŽLΓ©géñdārΓ½
Joined
Nov 30, 2002
Messages
10,861
Best answers
0
Location
Netherlands
That's pretty impressive. Intend to sell it on steam or Free to Play?
 

sub

Active Member
πŸ’» Oldtimer
Joined
Jun 18, 2003
Messages
5,961
Best answers
0
Location
New York
I'm going to sell it, at first in early access. It needs more work before it gets to that point though.
 
Member
βœ”οΈ HL Verified
Joined
Mar 1, 2002
Messages
877
Best answers
0
Just wanted to say I’m still interested in the game! Still looks super cool. I like the layouts you selected for steam, the story for the game is weird but I like it, motivated to take down some tyrants soon!

I had another gameplay suggestion but I don’t know if it’s easy to do or not:

I was rethinking the zoomed out fighting and maybe cut the maps perspective by a half, maybe make the guys 2x bigger. I realize that I think you played ESF with the view set to all the way back like that. Just a minor suggestion, I think this would make the game feel faster, allow for a bit more fine control for angles. However this is just from looking at it, I’m surewhen playing it might feel different-looking forward to it still, even if this request doesn’t go in.

other request I was thinking was terrain bombs, don’t know why, just thought it would be a fun motivator to try and hit someone in the same spot so that a bomb would get trigger if you got deep enough!

hope all is well sub!
 

sub

Active Member
πŸ’» Oldtimer
Joined
Jun 18, 2003
Messages
5,961
Best answers
0
Location
New York
Hey man, thank you for stopping by and offering some feedback. I appreciate it. I'm well by the way, I hope you are too!

I tried to outline where I'm at and what I'm planning. Feel free to skim this.

I agree with everything you've said. Terrain bombs would be fun.

The camera angle is something that I've been apprehensive about since I first implemented it -- The characters are definitely too small, and I think it'd help readability / help people realize what is going on if they were bigger. Maybe I was focusing too much on the zooming problem, where if you zoom in too much, you have less of a heads up for when enemies are nearby. It was basically the problem with grand theft auto 2, where you'll get into car crashes because the speed at which you travel is too great and the viewport too small for you to react in an intentional way. You can change the zoom level manually with mouse scroll, but yeah, maybe it is as simple as just increasing character size. I am thinking I will be more successful if I can directly solve this.

I've taken a break from game development to focus on paying work, so I haven't made much if any progress recently. I have been thinking about what I'm going to do, though, and I think my current plans are very ambitious and slightly radical...

* Make characters larger, independent of the zoom level
* Change the default camera to be more zoomed in
* Add a dynamic camera zoom, so that it can change zoom in appropriate situations (dependent on distance from enemy and your current velocity?)
* Implement an animation system. Right now the characters are only ragdolls which get forces applied depending on player velocity. Goes hand in hand with larger characters. These three points taken together mean I might have to adjust how quickly players move, but I think it's necessary.
* The terrain system is not great. I am going to rewrite large parts of it to be smoother, ideally coloring it to look like actual terrain. I read this article a few months ago, and the 2d side views of the impact are what I am shooting for.
* The game needs to have multiplayer
* More open development

I think if I'm to have any chance of success, I need to be as open as humanly possible in the development of the game. ESF would still not be released after more than 15 years if they waited until they felt that the game was complete.

So open development means:
* Releasing a free demo I'll call "9000", which will be the current game with slightly more polish (things like adding a tutorial). The current version is very incomplete and pretty janky to be honest, but I think it's reasonably fun, and illustrative of what I'm going for.
* Having a publicly visible todo list which I update frequently
* Open sourcing not just 9001, but all of my game dev work going forward.

There are two big projects I've been working on -- 9001, and It Usually Ends In Nuclear War, which is a 4x strategy game I am like 70% done with. They both are built off of a shared framework which provides things like an event loop, input handling, 2d primitive drawing, threadpool / job system for asynchronous work, save / loading system, (wip right now) a client / server networking solution, and some other stuff.

I am going to create a monorepo which hosts these two projects (+ any future project built off the shared framework, of which I have 3 more planned) going forward. Adding multiplayer means rewriting large parts of the code base though. I think how I'm going to do this is to start from a fresh code base which is multiplayer first. Even when you're playing single player, code wise it's all going to be treated as a local server running invisibly to the player. I'm going to piece by piece port the existing code to this setup for both 9001 and It Usually Ends In Nuclear War. It sounds like a lot of work, and it is, but I think it's doable in a reasonable amount of time.

Right now I'm writing a networked version of Conway's Game of Life as a test to make sure that I'm actually capable of accomplishing what I want to do. I still intend to sell the games commercially on Steam, I've just shifted my thinking after seeing multiple examples of open source games being successful.

Ultimately this all means that people can play the game sooner, but will have to wait longer for a 1.0 finished version.
 
Last edited:
Misanthropist
🌠 Staff
🌈 Beta Tester
β˜… Black Lounger β˜…
βœ”οΈ HL Verified
πŸš‚ Steam Linked
πŸ’» Oldtimer
Joined
Sep 18, 2003
Messages
1,406
Best answers
1
Location
Perth, Australia
Glad to hear the project is still alive in your mind. Its easy for even great ideas to remain just that and have protoypes fall to the wayside.
Network i/o and dynamic camera systems on state combinations and 'look ahead' can suck to make, but a great for learning and managing everything involved. I never got the knack of dealing with network stuff in a fast paced setup, props to you for digging in. Combining ragdolls and animation can be tricky at times too, but also teaches you a lot about dynamic constraints. At the end of the day, the whole topology and organisation is the most vital - multifunctional frameworks become very useful, particularly if you want a quick turnover and get paid :p

Good luck Sub!
 

sub

Active Member
πŸ’» Oldtimer
Joined
Jun 18, 2003
Messages
5,961
Best answers
0
Location
New York
Thank you. I think I'll need it :D
 

Users who are viewing this thread

Top Bottom