View Single Post
  #4  
Old 04-28-2012, 02:11 AM
Blackdog_kt Blackdog_kt is offline
Approved Member
 
Join Date: Jan 2008
Posts: 2,715
Default

My understanding is that the work on the sequel is primarily about 3d modeling and laying the groundwork at this point in time.

It's entirely possible to make "static" models in the meantime, but eventually each engine will handle these models differently to give them motion. One engine might do effects one way while the other engine does effects with a different algorithm, the same for calculating lights and shadows, etc, (and this is what results in the differences in performance and quality) but in the end they all take a 3d object and make calculations on top of it: the initial object that is being "read" into the engine can be the same, even if the calculations to be performed on it are different.

To give a simplistic example, it's like you have a bunch of oranges in your kitchen. You can just eat them, make them into orange juice, or extract the pulp and some orange skin shavings and put it in a cake, the oranges will work fine in every case.

I've taken up a computing degree course this year and one of the things they try to really press in all the classes i attend is modularity, especially for the so called object oriented languages.

To give you another example, as a form of practice for my computer classes i've taken up a project with a mate and we want to build an interface that will allow us to play pen-and-paper tabletop RPGs over the internet with other friends.

I don't know anything about how to handle databases, save data to disk or push packets through a network yet. However, i can still design and implement the interface of the application, as well as define categories of all the objects the game includes (with their proper attributes and ways to interact with them). So, what i'll do is exactly that, then i'll give the code over to my buddy and he'll do the rest.

There is no need for us to be doing exactly the same thing, nor is there a need to be able to do things at the same pace. It's like installing household appliances more or less. I can design my part of the modules (ie, pick some electrical appliances in the above example), the other guy can do the same for his share of the work and the we just have to plug it into a suitable outlet. Well, the power grid in that case is the programming language you use. And languages nowadays don't tell you "you can't plug in a fridge unless you first connect a hair dryer", they just let you plug each module in at your own convenience and, most importantly, take a module out, redesign it (to improve it) and put it back in.

That's pretty much what is being done with the sim currently. It's just that the module they are working on is being built from scratch and it's one of the biggest in the game. However, that doesn't mean it needs every other module to work correctly before it can function: new graphics engine will be just that, regardless of whether the switchology in the cockpits is corrected and vice-versa.

Now, both the previous IL2 series and the new one are built with languages that follow this method (C++ and Java for the old one, C++ and C# for the new one).

So, long story short, I can't tell you exactly how they do it, but i can understand the process somewhat to tell you it's not wasted time.
Heck, you could probably take the code that governs the systems modelling in the sim and port it to another sim with totally different graphics if you wanted to.

I hope this helps explain a few things
Reply With Quote