With Sc2 pretty much dead, is there any hope they are working on a Sc3? or is our only hope waiting for Frost Giant for a good RTS game next year?
ââNext yearââ lol, if they make a game it will take at least 3 years if they want it to be somewhat playable and it will be some kind of beta, not a full game and there is no warranty of it being good.
As for Blizz, no sc3 in the âânearââ future, who knows if they want to start making one in 3-5 years.
3 Likes
When I see a new Rog phone features, PUBG, COD, Fortnite it tells me where this tard company (Actiblizz) is going. The ignorance for the rts games that made them great is offensive
If Frostgiant made an RTS maybe they would first see how it goes if it was failure with the revenue they would probably not return ever again. If they could make a long played game like War3 and SC2 though, it would be nice, a lot of pro players would not play it as they might be too old to be pro again but at least this is the gen that likes RTS. Newer gens just want OW,Pubg,Fortnite⌠and Dota/LoL at best closest to strategy,
No.
There is also David Kimâs project/studio. But they are couple of years behind FG.
Hope?
No, there is too much overhype about it, most probably it will turn out to be a pretty meh game
As long as it has decent Campaign, fresh feel, decent RTS mechanics, it will do for me.
Rofl. The game play is implemented in the engine which is coded by the programmers. Itâs extremely complicated mathematics. Getting the units to move fluidly and interact naturally no matter what parameters you punch in for unit size, movement speed, etc, is an extreme challenge. Nothing else matters if they donât have grade A+ programmers.
Itâs also unlikely that the programmers who worked for Blizzard would be able to work for Frost Giant (non competition agreements are standard in this industry) and even if they could Blizzard almost undoubtedly owns the rights to the algorithms that make SC2âs units behave so well. In other words there is near a 0.0% chance they can make the unit interactions as natural as SC2 interactions feel. They would have to completely reinvent the method from the ground up and come to an equally as satisfactory solution. In other words a completely separate solution must exist to the same extremely complicated set of problems and you have to have programmers capable of developing and testing that solution (in the time frame allowed for the development as well).
In other words their best shot would be to import a programmer who has already done the heavy lifting, developed a separate set of algorithms, and pray that he is willing to come work for them and give up the intellectual rights to those algorithms. Thatâs the ideal scenario. A more intelligent programmer would license it to them and freelance the implementation of it into their engine, thus maintaining the rights to his algorithms and still getting payed. Another common solution is to offer a really nice paycheck and a guarantee for employment for X years. It guarantees the programmer gets payed nicely for his prior work and also guarantees the company gets his help to implement the code into their engine and to add on new features / bug fix as needed until the project is stable.
You overestimate the difficulty of this task by 2 orders of magnitude. There is no math involved at all (unless you mean rendering but even then it kinda doesnât and everything you might need is already implemented).
Normally in video game industry there are a handful of good developers and a whole bunch of students / grads who work crazy overtimes for pennies. Quality of code suffers badly from such approach but nobody cares.
every algorithm needed has been invented ~60 years ago
List them. There are thousands of algorithms each with hundreds of variants, and these can be combined to create combinations of novel interactions. So you need to be specific if we are going to have a conversation about this.
Not a single one of those people will be capable of implementing a system such as this and there is a myriad of evidence that proves it. Just compare other RTS games to SC2. If these programmers were capable of doing it, it would be done. RTS games are by definition much more difficult to implement than other game genres, so the lack of RTS games compared to other games like FPS/RPG etc is also evidence of the difficulty of the programming.
Nah its all about design.
And whatever publisher orders you to do.
Nothing comes even close to complexity of animation programming in any 3d person game. But its not some âalgorythmâ but just amount of straight work for whoever writes code. It is simple but it is not easy.
The only thing that comes even remotely close to âcomplex algorithmâ in RTS is pathfinding but even it has been figured decades ago. Anyway I donât see anything other than A* with at best some modifications in SC2.
First you need to prove that you are worthy of having proper conversation.
Link to LindkedIn profile would be enough for me. Or screenshot
SC2 is a game engine meaning itâs intended to do a massive range of functions, basically anything the designers could possibly dream of.
Uh, no. Animations are computed from bone hierarchies that contain position and orientation information represented in a position (xyz) and quaternion (xyzw). The positions of the bones are calculated by traversing the tree, applying the parent orientation to the local orientation. Any vertices of the mesh that are linked to the bone have the same transformation applied. Thatâs it. Itâs extremely simple.
Oh heck no. The command stack, fog of war, steering behaviors are all much more complicated.
Furthermore, A* wouldnât be sufficient for a game like SC2. The pathfinding grid is far too high resolution, there are far too many units. Itâs nowhere near efficient enough. Youâd have to simplify it with something like an octree. Now you have to build neighbor lists for the octree nodes so you will need an algorithm for building and updating those. Then when pathfinding changes for building placement events you have to rebuild the octree, the neighbor lists, and update paths only for units that had a path intersecting the changed nodes. You are going to have to compute the convex hull of the octree nodes for each path. You need an algorithm for that.
This is just the basics. It is a ludicrously complicated system. Letâs just take the convex hull algorithm for example. We will ignore how these algorithms integrate with one another and look at a very simple (and non ideal) convex hull algorithm:
Let points[0âŚn-1] be the input array.
1) Find the bottom-most point by comparing y coordinate of all points. If there are two points with the same y value, then the point with smaller x coordinate value is considered. Let the bottom-most point be P0. Put P0 at first position in output hull.
2) Consider the remaining n-1 points and sort them by polar angle in counterclockwise order around points[0]. If the polar angle of two points is the same, then put the nearest point first.
3 After sorting, check if two or more points have the same angle. If two more points have the same angle, then remove all same angle points except the point farthest from P0. Let the size of the new array be m.
4) If m is less than 3, return (Convex Hull not possible)
5) Create an empty stack âSâ and push points[0], points[1] and points[2] to S.
6) Process remaining m-3 points one by one. Do following for every point âpoints[i]â
4.1) Keep removing points from stack while orientation of following 3 points is not counterclockwise (or they donât make a left turn).
a) Point next to top in stack
b) Point at the top of stack
c) points[i]
4.2) Push points[i] to S
5) Print contents of S
Developing an engine is somewhat of an outdated way of creating games, specially for small studios. The way to go now is Unreal Engine. Even though u may have to develop some tools for ur specific games, is no where near the amount of work than developing an engine from the ground up.
There r just too many pluses for using UE:
1-cut developing time and money foccusing right away in game design and Art.
2-ur game can always have cutting edge engine/graphics because UE will always make previews version projects compatible with the latest iteration. As of right now UE4 projects can be ported to the upcoming and amazing UE5.
3-many technical and complex tasks are reduced to a third party that is very user friendly. Generally, you are obligated to pay Epic 5% of all gross revenue after the first $3,000 per game or application which is pretty acceptable. Blizz right now owns 100% of what u do in their engine, talk about outdated ways.
This is Warcraft 3 ported to UE5 by a fan, still a work in progress:
Thatâs like saying you are going to build a rocket and fly to mars powered by an engine pulled out of a honda civic. If you are going to create a game that uses easily available tools then by definition you are creating a vanilla clone of already existing games. You arenât going to be flying to mars in that thing, you are going to be doing all the sorts of things that a typical honda civic can do.
Successful games implement novel ideas which by definition require custom engines.
Rofl. This is exactly what I was talking about. If you want to live in the past, cloning the same old games on repeat, then be my guest.
I do believe Blizzard will go bankrupt within the next 10 yearsâŚprobably less than that. My guess is that Blizzard will have to sell the rights away to their major titles. Then another company could buy the right to the Starcraft license and make a SC3. Thatâs just my two cents. But lets be honest here Starcraft still has at least some popularity behind it (even if itâs dwindling) whereas Blizzard as a whole has lost most of the popularity it ever had. So with Starcraft being more popular than its developer this situation is bound to happen eventually.
Nah, its not how it works: you do bare minimum of what is needed and add features that designers ask for.
Dude I wrote such code.
The only hard part is not to die from boredom from writing this sh!t and not drunk yourself into alcoholism from hating your life and your job.
All stupidly easy.
A lot of work of course, but all of it is an easy and boring kind of work.
It is adequate enough.
If grid is too big it is separated into several grids and path is first computed between âbigâ grids than small paths are calculated in smaller grids.
Or just use navigation mesh and Dijkstra. Nobody cares.
You can also share calculated path between several moving agents when they moving from about the same point to about the same point to avoid having calculating very large number of paths at the same time (I actually wrote such feature back in the day).
Problem with large number of agents is solved via colliders that push agents around each other. Now we used havok for that however writing such - very simple - âphysicsâ is easy. Me and my friend actually implemented simple shape colliders for WarCraft 3 via WarCraft 3âs scripts while we were first year students (somewhat brute force implementation - computing power of 2005 PC was enough for about 90 such âcollidersâ that used wc3 scripts (jass) for computation that were at least 1000 times slower than c++ compiled code).
One can spot this approach by noticing how units form âstreamâ when moving from one point to another which is exactly what is happening in wc3.
Moving in formations though is also easy and is only couple days of extra work on top of working navigation system.
And how are you going to decide which areas are big and which are small? How are you going to decide which areaâs edges intersect what other areaâs edges and how large are these intersections? How are you going to deal with units smaller than the grid size, and units larger than the grid size? A* and similar algorithms only find a 1D line. How are you going to compute the full area of the walkable path? How do units utilize the full walkable area of a path while still following the path? Are your units going to hug the center line? How are you going to compute if a unit is too wide to fit through an area? Are you going to compute path widths? But those would depend on the unit parameters and what kind of terrain they can pass. So are you going to calculate widths for every unit type for every pathfinding node? How are you going to update that if the pathfinding changes, e.g. when a building is made? Do you compute widths per node or instantaneous widths? Widths in between nodes definitely change so if you donât compute instantaneous widths units could get stuck. I could go on and on.
Just split the grid into squares of equal size. Because it works.
In case you are wondering how we going to determine whether on square is connected to other - it is done during scene exporting. Or even manually, by map designer. Not in runtime, not during loading. Cost is zero.
Map in WC3 and mist likely in SC2 have several different 2d grid maps - pathing map and height map. Thatâs good enough.
Modify condition of whether cell is considered pathable or not.
Granted I used this approach for my personal fun project and not for an actual game (to make cavalry unit take 3 hexes instead of one - worked with no glitches).
For an actual game we modified distances from nav mesh border based on unit fatness when doing path request. That was for Dijkstra though.
Answered above.
In StarCraft they generally donât. Units also push around each other by their colliders so large mass of zerglings on short distance might make appearance as if they are walking in ball, but if you order them to move in long enough distances you will see them forming perfect line and clumping in choke points and around corners.
Making units to walk in formation is also pretty trivial if you use a navmesh. I canât think right out of my head how it can be done via A*⌠But I see no reason why both A* and navmesh could not be used at the same time for different tasks.
When unit fails to move on its path for whatever reason it sends a message and behavior tree reacts accordingly.
More interesting case if you want to make units react instantly to something or avoid certain zone (which doesnât exist in SC2 but whatever) - first is done by sending messages to unit crossing this particular node (you make node have pointer to unit that is crossing it) and second is done by âcoloringâ affected nodes: color either increases âcostâ of traversing through such node or allows you to modify conditions in path generation. Modifying cost is more universal and âalgorithmicâ approach but it looks stupid more often than not.
Dynamic agents are ignored during pathfinding - units are pushed by their colliders. You can see this if you look at units in SC2.
Things like buildings modify cell âcolorâ.
If units get stuck it sends a message and its path is recalculated. Or its not and unit stand in place sad and stupid, like SCVs that were rallied to natural while wall on main is closed.
I can do this all day. Navigation was one of things in video game programming that were interesting. One of few bright spotsâŚ
If you think you see units in video game do something smart - they donât. In video games programming everything is faked, like in pornography.
Hmm Iâm partially developing on my own and I still wonder why Unity is used so much. So many times things break after update, installing diff versions.
Havenât tried Unreal idk how good it is for strategy and how demanding for performance. But I know nice games made with it recent years. They may be less glitchy so I agree with them better using UE than making their own engine
Keep in mind such graphics are not so fit for micro game like Warcraft 3. Ever since they made Reforged the new models look harder to distinguish and u need to recognize units in flash
Cause its easy and allows you to start making actual gameplay immediately after you installed Unity.
Just compare it with how much time it would take you to set up e.g. OGRE to render your scene⌠or write a scene exporter from e.g. Maya (Maya plugin writing is a sacred lore known to the few).
Writing bare bones render engine from the scratch will take ~half a year of experienced render programmer working full time (according to my friend who is render programmer with 15+ years of experience and team lead badge)
I mean they are working on an RTs but itâs gonna be awhile.