The discussion on this thread is strictly about constructive criticism in the hopes of providing feedback to GPG that could lead to the production of a better moho engine. I ask that under no circumstances participants in the discussion engage in dialogue about subjective likes and dislikes of particular games, gameplay features, changes, etc. - lets keep things technical and discuss these aspects only in the strict context of their impacts on the moho engine.
After playing SupCom 2 and comparing the engine's performance with its predecessor, FA, I have observed several things that I believe limit the moho engine from achieving its full potential.
While GPG has improved the moho engine since FA, I believe that there are things still remaining at the core of the engine's current implementation that need to be fundamentally corrected if the moho engine is not to be a "system killer".
While playing SupCom 2 and FA, I have often noticed that despite having an adequate graphics card and putting the settings all the way down, the games experience slow-down, yet the cpu is not taxed at 100% usage nor have my other system resources, such as ram, been exhausted. This suggests to me that there are underlying issues yet to be resolved with the engine's algorithms for processing gameplay as efficiently as possible.
PATHFINDING
When a unit is directed to go from point A to point B, the engine would calculate a path beforehand how that unit should travel across the map/terrain in order to achieve its destination; once the path is calculated, the unit is sent on its way. The FA engine uses the A* algorithm for this calculation, while SupCom 2 uses something called FlowField. Essentially, A* would calculate the path for each unit of the game exclusively. On the other hand, FF attempts to reduce the number of necessary calculations by calculating paths for clusters of units.
I will come back afterwards and fill in the blanks describing these algorithms in greater detail. First, I would like to propose a new algorithm that I think would eliminate a lot of overhead for the moho engine in that the engine does not actually calculate the path in advance. That's right, the engine does not actually calculate a path. I call this approach: madpath.
- A*
- FF
- A* + FF
- madpath
All information for how the unit should move across the map is encoded in the map itself and the unit simply navigate where it should move as it moves. The only thing the engine would need to calculate prior to movement is the direction from point A to point B. Now, let me explain.
Every type of terrain is represented by a different value that differentiates it from other types of terrain. Each type of terrain has a radius of effect that tells nearby terrain that it is there. Think of an expanded chess board with all the individual quadrants. Now, consider that we are dealing with uniform terrain that is unelevated. Let's denote all the quadrants as 0. Now, let's alter the center of the board to have some water. Let's denote the water quadrants as 10. Also, lets say that for every quadrant of water, there is a radius of effect for 5 quadrants away. So, from the perimeter of the water quadrants, all quadrants 5 units away would be denoted with decreasing values to denote approximately how far away from the water those quadrants are: 10-1, 10-2, 10-3, 10-4, and 10-5.
Now, let's say our unit is in the bottom-left corner and wants to go to the top-right corner. The water will obstruct its path. But the unit doesn't actually know this at the outset, but begins moving anyways. The engine would only need to calculate the coordinates as follows, for example, Point A = (1,1) and Point B (1000, 1000), and determine the direction the unit needs to go.
The unit moves from quadrant to quadrant, and since all quadrants up to this point are all denoted by 0 (flat terrain), the unit just keeps moving in a straight path unimpeded. As soon as it hits a quadrant marked as 10-5, it knows that water is up ahead. At this point, the engine would start examining the nearby quadrant by a small radius to determine the 10-5 and 10-4 boundaries, and adjust its path accordingly.
Now, suppose there is a cliff just a little bit away to the bottom-right of the water. Let's denote the cliff quadrants as 20, and the non-cliff units in a radius around it as 20-0, 20-1, 20-2, 20-3, etc.
Each quadrant can have as many values as needed in order to inform about the nearby terrain. So, a quadrant can itself be 0, but also be 10-5, and 20-2, i.e., you are on flat terrain, close to a cliff, and nearby water. From this information, the algorithm dynamically grows its scope of examining nearby quadrants for information only as needed. Otherwise, it just keeps moving one quadrant at a time with no overhead calculations since each subsequent quadrant nearby has the same value. Remember, the 10-5 and 20-2 squares don't actually represent the water and cliff. They are only informing of upcoming changes in terrain type and how far away those terrain changes are to occur. At each step, the unit is only examining its immediate surroundings, but with an overall compass needle pointing in the direction it should go.
It is often the case that the gamer will change the desitnation several times. In each case, A* and FF would have to expend resources to recalculate the new paths. With the madpath approach, the algorithm does not have to recalculate the paths every single time - it just needs the coordinates for the current location and destination. Everything else will be analyzed in real-time from the map as needed.
Exposing access to the Attack Manager, Navigator, and Intel would be awesome. FA already lets you access the Nav. moderately well, but the incomplete Attack Manager communicates to it behind the scenes and any time you attempt to reach the Attack code the engine dies a horrible death.
Better access in the User layer would be nice too. That's mainly adding a few functions to fetch units, and not a major re-architecture.|||I dont think this is a useful thread. In what ways can any engine be improved?
1. Performance:
Sure, you can say, "the game slows down when it doesnt seem to need to", but thats pretty meaningless - basically just, "make it betar plx!!". Without access to a debug version running a profiler, noone knows where in the code slowdown occurs other than GPG. CPU utilisation is a poor judge since I assume windows software needs to leave some juice available for background apps as good practice.
I guess if you have extensive testing and can pinpoint specific problems (like Bodaboom effects causing framerate loss, a bug that caused a workaround patch) then there are things to report. But thats not an engine improvement, thats a bug report.
2. Rendering features:
I'm not up on the latest 3D gfx jargon, but a wishlist of fancy new features like DX11 support or Pixel Shader whatever is pretty obvious - the more the better, constrained by budget, accessibility, compatibility etc.
3. Moddability, custom maps, etc:
Its pretty obvious that some people want it. The reasons for not having it are out of our hands, and possibly GPGs as well.
4. Modding features:
This is probably the only useful area of feedback, and only for modders/people using the engine. Function X being inaccessible, Function Y not working properly, Function Z needed but currently missing, etc.
But... SCom2 modding is not officially supported, so feedback on SCom2 wont have any effect on patches. KnC is supposed to have modding, but feedback on this is best given when people have a chance to look at the code for that version of moho and play around with it.
There's a body of knowledge with what's lacking in SCFA modding, but the ship has sailed there so there's no point.
So there, a short essay on why this thread is useless. What kind of responses were you hoping for? Is this just a platform for you to complain about SCom2 again?|||Why are you talking about modability? That has nothing to do with the game engine.
Anywho there is no point in this thread madface, as you don't know ANYTHING AT ALL about ANY of the algorithms or code in the engine. Nobody except the actual coders of the engine will be able to talk to you about it, but seeing how you talked to servo he probably told them not to waste their time with you.|||TheWord|||Write a demo, patent it, and go make some millions then ;)|||You would need to have the grid to be sufficiently small to allow non retarded movement, which would lead to really high CPU usage continuously for moving units.
This also doesn't address any conflict of paths where there are more than one unit trying to occupy one small grid block. If you added something like that into your algorithm it would increase CPU usage across the board continuously as any substantial unit groups move.
EDIT: Actually no. It's a brilliant algorithm that you should go make compatible with the moho engine. Come back to use when you have a working model.|||AdmiralZeech|||TheWord|||DeadMG|||Quote:|||TheWord|||TheWord|||The problem with the model that you posted is that it's only local- if you start to have strange-shaped terrain, which doesn't follow the predictions you make from your starting point, then it won't work correctly and the unit will travel a suboptimum path. The idea of a local pathfinding is new, but that's because it's insane, as you can't possibly guarantee an optimum path without finding one all the way to the destination. A* and FF however both guarantee optimum pathing every time. More importantly, you're seriously going to invoke performance problems checking the map over and over and over again, whereas A* and flowfield run one check, and then can leave it.
Quote:|||madface|||DeadMG|||TheWord|||TheWord|||I'm using the tile-by-tile analysis for illustrative purposes, but it's not necessary to have a strict tile-by-tile analysis.
Each tile can have a certain radius of "x" number of tiles away, but still local. If the unit is moving in a particular direction for which it is predictable that unit path wont change, then it is possible to just set a flag not to include this unit in subsequent scans until it reaches its destination.
However, weapons targetting or a friendly unit coming in scope etc. would set a flag that reactivates the unit and reexamines the path movement immediately upon the next scan.|||LOL, if you say so.|||TheWord|||BulletMagnet|||Is this gonna be more pointless arguing about pathfinding algorithms that probably don't even apply to KnC's subdivided pathing methods that we know little to nothing about?
Regardless, I'll go ahead and answer the title question based on what little I know about how FA and SC2 work:
1) All but remove lua from the game, keeping only enough so that new units can be added and some basic unit event scripting done. Maybe keep a few UI methods exposed, so that some basic UI scripting can still be done, e.g. unit selection/filtering, etc.
Whoops, looks like SC2 already did this, and it's no surprise why its UI is ten times as responsive as FA's and the sim only slows down under ~2x the object density. Actually, the game would still be quite moddable if SE had any interest whatsoever in allowing a mod manager (they don't, and won't, which is unsurprising considering that they're a big multinational publisher whose games have never had mod support).
2) Reduce the number of projectiles, weapons and (only if necessary) units in play at any given time, particularly in the end-game. Regardless of how brilliant your physics algorithms are, if you're calculating firing arcs, ballistic travel, and collision for ~10,000 objects at any given time in a single thread (necessarily), you're going to have problems. SC2 blew this one by giving up its late-game performance advantages to a ridiculous increase in projectile and effects density.
This isn't an engine improvement, so much as a compromise with reality. Show me another real, playable game engine that can handle the object density that FA and SC2 routinely produce with less CPU cost.
Notice that I didn't say 'prattle endlessly about algorithms, blah blah blah I know quantum mechanics'. Show us an example where someone did it better, where the improvement can be understood, qualified, and likely implemented into GPG's engine.
3) Take the AI out of lua completely, again exposing only the minimum needed to add support for new units. I honestly can't believe that FA's AI runs as well as it does, while being anything close to a challenge. Of course it's not known for its strategic brilliance or ability to adapt to changes, but creating a serviceable AI almost completely in lua and expecting it to not consume massive amounts of CPU time is entirely too lofty a goal. I haven't looked directly at SC2's AI, but from what I understand, it's still largely based in lua.|||BulletMagnet|||Mithy
No comments:
Post a Comment