I would love for someone from Uber to answer this - Someone stated that the unit cannon was very difficult to implement in PA and I was wondering why from a technical perspective(aside obviously from the time spent). I'm studying programming and am about to start trying my hand at Game dev and my thoughts were would it not be a case of setting up an animation of the units going into the cannon, deleting the original whilst adding it into an array then shooting that array object across (I'm assuming this is the complex bit? Surely it would be similar situation as nukes going inter-planetary?) Then once the object reaches the destination you animate it again to show it unfolding into the units and recreate them at that position? Also, someone mentioned it would be very different to how you implemented it in Supcom 2. Why is that? This is in no means a "Hurry up and GIEF UNIT CANNON thread" just wanted to know what the technical bits behind it is ^^
I imagine much of the difficulty is not in the technicality of programming, but making Unit Cannon a useful and balanced part of the game. In order to add something as conceptually complex as an interplanetary Unit Cannon, one needs to consider strengths, weaknesses, how an opponent would counter, unit cost, etc. In SupCom 2, the Unit Cannon had a range similar to the Experimental Artillery, so before you could use it you needed map control of an area close enough to the enemy's base that I usually just drove my army in manually...! However if you want to have interplanetary Unit Cannon then that simple act of balance, range, is no longer so simple. I will leave the balance discussions to those more qualified. Going back to the technical side of things, it would be easy to whip up a prototype in the way you describe. That's not the whole story though. You need to fully design the piece before you implement it. You need to test your design (that's where the balance discussion starts). Then you make a prototype, test again. How about a full implementation? Great, now some more testing, you need to teach the AI how to deal with this new threat/opportunity/strategy, QA, bug fixes, and finally you can include it in the Gamma. At the moment, these resources at Uber appear to be focused on larger set-pieces like Galactic War. I hope this helps for you to see how something which seems simple to execute can in fact end up being very complex and a big tax on resources at a small firm like Uber
You raise valid points, but I'm trying to disregard the balance sidearms just focus on the programming side- ie make it functional. I'm sure to balance it they would make it so you can only shoot from planet to its direct moon or vice versa, hence a need for changing orbits to be functional again. But obviously there are other considerations.
There are threads on this in the past. Uber went into some detail about it – somewhere... Essentially the issues are the same as the multi-unit transport, making units line up and enter into the cannon smoothly takes a lot of work. Then there's the firing process. Then there's the flying from one planet to another (that system is already in place, so shouldn't be much of an issue). Then there's the units gracefully falling down to the planet, losing their jetpacks and entering combat. Sure it'd be easy to delete unit and store it in the cannon, then turn the unit into an interplanetary nuke like thing, and then make it appear on the planet. It's the animations and transitions and the many many different kinds of graphical glitches that could happen when moving units in and out of the right position. The animations become a lot more difficult when many units are involved. They get caught on each other, block each other, need to make sure to let other units through and not get in a traffic jam... And those same reasons, minus the interplanetary travel, are why we don't have multi unit transports yet. I know I'm not an Uber developer, and I'm just paraphrasing some of the stuff I've read, and adding in some of my own conjecture. But I hope that helps.
As far as I can tell most of the systems are already in place. We already have units lining up to enter something and the use command with teleporters. We already have transports and interplanetary transports along with interplanetary movement speed settings. We already have unselectable carrier units (rockets from the orb launcher) that can vanish after dropping the unit down. I'd think that it would work like this: The units enter the teleporter and get loaded into unselectable phantom transport units. Upon giving the UC a launch order, the phantom transport units (Would they even have to be phantom/invisible? They could just be a simple box with a texture ala the concept vid) are launched towards the target destination. Upon reaching the air layer over their destination, they explode and the units are dropped. Much less hacky than Brian's idea. Could someone explain to me what the roadblock is?
If the unit cannon fired canisters with units inside rather than whole units, that would remove the animation stress. As for units dropping into the same location and running into each other, the cannon would have to have at least a little inaccuracy, so that's not really an issue. Even then, it could be coded to not fire at a location that it's already fired to until that location is clear.
Only issue is the unit does not get from point A to B instantly, I see space aircraft stack all the time, so I see no reason units couldn't have code in them to allow them to stack when landing on top of whatever they land on (as long as it is terrain the unit can navigate, and if ti is a building/mountain it would just teleport to the side of it as they do now when a unit stays in the factory too long and/or when a factory starts being constructed on top of them). I do think the canister idea is far more feasible in terms of realism and development... just tack on a parachute or rockets to make a landing animation, then the unit(s) file out
u know...there could be a fun way to solve the issue of micromanaging the unit cannon/working properly. Why not make it have a life of its own?/self automated? here me out The unit cannon, when a nearby planet/moon is in the feild of sight/range of the unit cannon will fire any units loaded/queued into the cannon automaticly, the canisters (like seen in the kick-starter trailer) will drop units randomly....but in a much larger and more random area, like half the side of the planet radius...that way you can have support and find beachheads where you can get your units together for real strikes, while the enemy of course, has a chance to wipe all the units out before they combine. This will hopefully remove any difficult micro managing, and people can consider taking nearby moons before attacking the main citadel, where they can draw support from. What inspired me was D-Day WW2 and the paratroopers and how at first they where scattered everywhere and it was general chaos until they grouped up and posed a real threat
I never suggested my "5 minutes of thinking" was the entire process. I was asking what it would boil down to in an actual implementation. I would just love to know what goes into programming something like this in quite a detailed fashion
I fixed yer quotes. Not sure how exactly that cuts corners. What functionality is missing in it? I don't ask these things because I think I'm smarter than Uber or anything. I ask these things because I'm genuinely interested in what the issues are that prevent my idea from being feasible. I'm actually quite curious as to what prevents Uber from doing something such as what I said and making the UC that way.
Most likely that the unit canon - in that form - collides with the far superior orbital system, including the Astreus. If an assault is to have any chance you would have to send in ridiculous amounts of units via the unit canon. You can hoard Astreaus, but even if the unit canon had a burst fire mode, it wouldn't be able to send in more than 5-10 units at most. So you would need to spam UC in oder to get them do anything useful. And then again the issue with the versatility of the unit canon: It's almost non-existent. It's only usable for shooting down the gravity well, that means from moons to planets, or for on planet transports. First one is such a rare occasion, it's simply not contributing enough to the gameplay in order to justify the time investment for the development. And the second? Current planets are far to small for that. Maybe again once we get SupCom sized maps with travel times in the magnitude of 10-15 minutes for ground units, but until then going by foot is usually sufficient.
Where is everyone getting this info from? I haven't seen it anywhere. I still think it would be cool to see 5+ UC standing there blasting units into another planet, while dropping fabbers to build teleporters etc. I would think it would be balanced like Supcom 2's. Where it shoots a couple at a time.
There is a lot of information on the unit canon to be found on this forums. The gravity well issue is the one which is best documented, it results from the fact that the capsules are not supposed to have active thrusters, which means they can't perform orbital transfers. If they had, they would be equal in role to the Astreus. The other ones are simple implications.
Actually huge unit buffer in unit cannon would help with late game lag, esp if AI would load all those units inside cannon instead of lagging out everything. Also I do not see reason why not to make unit cannon overpowered late game structure, same as halleys, there is no counter to them. Why unit cannon cannot be kind of doom machine to launch 100s units at once. It could have quite low HP and when destroyed all units inside would also be dead. Recently i played Galactic Bore Wars just to see it. And my allied AI produced so many tier 1 units that i could not play anymore, so i nuked my own ally commander. Planet was conquered and secured, but i could not do any moon invasion because AI made around 2000 units and then moved them around to kill single landing astreus. Unit cannon would help with this if AI by default loaded all units there and if it had huge buffer.
Among this information is the fact that we get it at release. Oh wait.... Things are always subject to change - I don't see any reason why the UC wouldn't be able to do orbital transfers.
