Hacker News new | past | comments | ask | show | jobs | submit login
Supreme Commander – Graphics Study (adriancourreges.com)
162 points by mariuz on June 24, 2015 | hide | past | favorite | 31 comments

What a phenomenal writeup.

What I'd really like to understand about SupCom is how the zoom in/out views are so smooth and seamless.

At one point during the beta I remember talking to a dev on IRC who told me the zoom was very challenging in this game, and that a novel approach had been devised and successfully implemented.

The scale of the range between micro and macro views in SupCom is unlike anything else I've encountered. For example, you can start zoomed in on a specific character on a ship, and then you can zoom out all the way until you can see the entire map. And the whole interaction is for all intents and purposes seamless and smooth as the view changes.

It's akin to the intro part of the film "Contact" where it zooms out from the Earth all the way into the deep universe.

Such a gem of a game -- too bad it takes so long to play a round! (3-6 hours+)

This is mentioned in the linked article but a lot of the rendering work is done in the Level of Detail system that is standard in most game engines now. As the player camera moves further from an object, lower resolution versions of the 3D model replace the default high resolution model. Supcom takes this a step further, and at the furthest zoom levels, switches to a 2D sprite (a single quad with texture applied) for unit meshes.

Other games have implemented this sort of thing now, like Planetary Annihilation, which was created by some of the original SupCom developers (warning: don't buy PA unless it's at a severe discount however as it's buggy, has poor game balance, no good single player campaign and a tiny multiplayer community).

The Kerbal Space Program game's devblog also contains some interesting writeups regarding this kind of thing, like this one:


This blows my mind - how many years of programming must you have under your belt before you can even comprehend writing something like this?

Are these established methods that you can google and pick up anywhere, or is there a lot of experimentation going on to see what works?

Not exactly years of programming. But years of studying computer graphics, as applied to games.

I bet I could show this article to myself back when I started CompSci and be able to comprehend most of it. But I was a Gamedev.Net addict, tried my hand at competitions and tried to write my own 3d engine. At some point, my mathematical knowledge became the bottleneck.

There are a lot of established methods, you can pick a lot by reading SIGGRAPH, but that's too heavy early on. If you are truly interested, you should start by learning how to put simple 3d geometry on screen. Then, when trying to figure out how to make things look better, you'll naturally gravitate to learning what you need.

Nowadays, it is much easier to start, since we have WebGL and all you need is a browser and javascript. On the other hand, shaders are now a mandatory part of the rendering pipeline, so you need to learn those.

When trying to apply these techniques in real games, there's indeed lots of experimentation. And many times game developers come up with novel techniques. See papers by Valve, for instance.

It's not that mindblowing, although it does require a chunk of maths. It's only really the shadows that are complicated. And yes, it's a stack of established methods which have been built up over decades. SIGGRAPH is a good place to start, and there are open source 3D engines (including the ID software ones) to refer to.

"Mindblowing" are the demoscene people who fit this (or something more complex with procedural generation) into 64k or 4k binaries.

I finished an MSc course in Games Engineering and we covered 90% of things in this article. For the final project we had demos with pretty much everything covered there + post process shaders + deferred lighting + DX11 tessalation shaders + ambient occlusion.

So yeah, I think you can find very good uni courses which cover those things, but they are not very common - I know I can certainly recommended mine, I got a job in the games industry straight away after it.

Which course was that?


Literally every person that I knew who was on this course is now either in a job(in games industry) or doing a PhD.

Ah thank you for sharing. Wish I had access to something like this when I was in college. Might I ask what the textbook/s were for this course?

Textbooks? Seriously, I finished a BSc Computer Science degree then did MSc in Games Engineering and never had a single textbook. Lecturers would hand the notes out(but they were also available online as pdfs), that was all that was needed.

Edit: obviously there were books which were "recommended reading" but very few people bought them, they were all in the library anyway if someone needed one. I think you can see the list if you click on "modules" and then click on a specific one, it tells you the structure of the module and recommended reading.

Both. You can find existing references for each one of those techniques, and even for the architectural concepts behind an engine. But you have to figure out which techniques are the right choice (you may need to invent some), and how they fit together, for the needs of your particular game / style / style.

Nothing to do with years. Graphics programming is a specialism

If you like this, you'll probably also appreciate this earlier study by the same author:


At my first internship, I handled the GUI for an application used to simulate networks on a large scale (I remember 20,000 machines being the "small" test-case we used). There was a view where you could watch all of the devices in the network, and could zoom in/out to see the entire network at once, or individual devices.

I remember playing a lot of SupCom to help me get an idea of how to zoom smoothly and how to handle the overlays/information density at every scale (also because it was a badass game).

This write-up is very interesting and very well structured.

I can't help but think about the fact that the SupCom engine performs horribly while reading this, though.

It does worse in almost every respect compared to even the engines that came before it and while SupCom is definitely massive scale, that's not the root of why the game's performance is very poor.

Awesome game, and a very detailed writeup too.

Agreed. It's a shame the sequel was such a step back in every respect.

What do you think of Planetary Annihilation?

Not enough viable endgame strategies, not enough units/factions/styles. Not enough mods, not smooth enough control/UI/UX.

Other than that, then engine is amazing, the concept is solid, the potential is there, the possibilities are endless! ChronoShift or what's that nifty feature is amazing for keeping long games in-sync with each other, and so on.

Currently Zero-K delivers the most fun in terms of time and money investment needed.

It was a disappointment for myself. The 3d planets was interesting, but not in a big way during actual gameplay. It actually made the UI a little more annoying and just didn't reach the level of the professional UI of Supreme Commander.

Supreme Commander is still the best I've played and it is still going strong under the Forged Alliance Forever community. http://www.faforever.com/

FYI: Chris Taylor now works for Wargaming. There has been no word yet on what project he may be doing there.

> FYI: Chris Taylor now works for Wargaming. There has been no word yet on what project he may be doing there.

Wargaming bought Gas Powered Games in 2013, thus Chris Taylor works for them. Within months, Wargaming additionally bought the Total Annihilation rights from the THQ bankruptcy auction. Taylor is likely working on a TA sequel.


i was seriously disappointed with it as well.

Zero-K (which is a free TA Ripoff) is gameplay-wise worlds superior. i felt cheated paying so much for planetary annihilation.

Disappointing for me as well. It don't regret backing it in the slightest since it was the best chance by far to get another SupCom-like but it is flawed at best.

The units are mostly uninteresting. I don't know why they have separated the land factory into vehicle & bots factory, they seem mostly interchangeable to me. The stratospheric & inter planetary game-play is very limited (you have only one type of attack satellite that you mass produce).

The UI has some catastrophic oversights. Even if you have visible coverage on a whole planet, you don't get any alert if an enemy sneaks in (only when he/she attacks). So you have to constantly monitor all your planet(s).

Procedural generation + round planets creates maps that IMO are not very interesting.

I haven't tried it to be honest.

There's still a very active community of Supcom Forged Alliance Forever players. If you want to watch some great gameplay check out Gyle's channel on Youtube.

As a non-graphics guy the complexity of 3D games rendering is just mind blowing.

Makes me feel a bit guilty that I play it in the 2D view.

For me, some 2d games are mindblowing. It is a major pain to have a 2d isometric game with overhangs. I'd rather do it with a 3d engine.

It's articles like this that make me sad that I never took linear algebra (I would have loved it, but I flunked the advanced calculus course prior, so that ended any major ambitions that had a math requirement)

I took linear algebra, performed adequately, and the only time I ever found it useful was when I was trying to get a grip on OpenGL. After hanging around a lot of indie developers I discovered that having knowledge of low level graphics programming is not as useful as say, being artistically capable. A lot of devs rely on content creation engines like Unity so being proficient at low level graphics programming isn't exactly an asset.

I remember that game being very playable and fun. I especially liked the zoom feature. It is missing in modern RTS games. It really adds a lot. I loved how it switched to icons as you zoomed out.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact