The IWD2 engine hardcoded a lot of behavior to make it 3E-ish (some 3E rules couldn't be implemented, like Attacks of Opportunity). So, reproducing the 3E functionality means re-writing from scratch or turning decompiled binaries back into something that can be integrated into the IE+ engine.
And don't forget, the IE+ engine has been migrated to 64-bits, so you'd have to update the decompiled IWD2 code to 64-bits while integrating it to the IE+ engine.
The easiest path to IWD2:EE would likely be porting the *content* to the IE+ engine, i.e., the AD&D 2E rules (w/some Player's Option additions).
The IWD2 engine hardcoded a lot of behavior to make it 3E-ish (some 3E rules couldn't be implemented, like Attacks of Opportunity). So, reproducing the 3E functionality means re-writing from scratch or turning decompiled binaries back into something that can be integrated into the IE+ engine.
Presumably there's a large part of the IE that they can reuse, otherwise they wouldn't have used the IE to begin with. I still don't see this as an impossible task, quite possibly not as hard as imagined either. Don't forget that the compiler generates a lot of boiler plate code. But again it comes down to the skills available in house to actually pull this off (not because they aren't smart enough). I'll concede that in the commercial space there's not many people who's got the skills to do this and even less in the gaming world. I do know that my friend who started grinding gear games possess this skill (he unfortunately doesn't do much coding now a days), so it's not unheard of.
And don't forget, the IE+ engine has been migrated to 64-bits, so you'd have to update the decompiled IWD2 code to 64-bits while integrating it to the IE+ engine.
Again I don't see this as a hurdle, remember the compiler does most of the heavy lifting when converting to 64 bit. You don't alter the way you write loops or conditionals etc. for 64 bit. Sure it's not always a simple case of flicking the switch on the compiler to get working 64 bit code, but it's not a major issue since you're going from 32 bit machine code to 32bit asm, then either you recode the C/C++ by hand or get some wonky decompiled code. IDA actually does a reasonable job, I've used it with great success in the past. From there you just move forward down the 64bit path. The hard part to port is pieces that talks to hardware and windows API's etc. but for the most part these would already be done in the IE+
The easiest path to IWD2:EE would likely be porting the *content* to the IE+ engine, i.e., the AD&D 2E rules (w/some Player's Option additions).
This is correct, but I still think there's value in looking at the old binaries and I don't think that they need to move it to 2E rules (even though I know a lot of us would prefer that), since I don't believe that the amount of code that needs to be reverse engineered is that much, again not calling it trivial but you won't have to do the whole engine. None of the rendering code will have to be revered, or if so very little.
I'll make another concession here, but again it's not a read block. Game devs aren't known for writing well structured and maintainable code. So the possibility exists that you'd need someone who can figure out obfuscated code. Not a huge issues but takes a bit more time. I'm not talking about code that's run through an obfuscator since there's known techniques for dealing with code like that. I'm talking about stuff that gets obfuscated during the course of writing code, fixing bugs and shoe horning features in. Now don't get me wrong I'm not dumping on game devs here, they usually have time pressure so I understand why things end up this way. I've also seen this more times than I care for in the "real dev world", but again nothing that can't be dealt with.
I said I was done ranting ;(
Also I need to state for the record that none of the stuff I'm talking about is rocket science, most devs are just scared of by it because they don't know where to begin. I know hackers who reverse code all the time and mess with good developers code, those same hackers can't code worth a damn. You don't need to be a genius to do this stuff, it's just a bit different. I really wish more devs would take an interest in this stuff since the security landscape would look a whole lot different if that was the case. If you consider that the buffer overrun is still fundamentally the most common type of attack (I'm not talking specifically your stock standard buffer overrun attack, but a variation on the concept, eg heap spraying).
I really should stop reading forums... I'm going back to sailing my boat now...
Some so-and-so must have the code, perhaps a worldwide call with a suitable reward is necessary, an invite to the launch party, say.
Thats not how it works.. This requires the company that owns the source code to assign someone to make sure its archived and maintained, and most dont do this. If they do it usually gets lost down the line, once the app/game is no longer an actively developed product of said company (or worse, the company/publisher goes out of business and with it all the data). There have been plenty of cases where companys/devs have lost or never backed up source code and have been powerless to do anything to fix an app or game.
Its kinda like being in a band and recording an album at a professional studio. Unless the band/record label goes in and specifically pays for a copy of the digital song sessions, or the tape they are using to record it, all you walk out with at the end of the day are copies of the stereo masters of the final mixes you did. AKA that actual material that is going on the album. Meaning 10 years down the line, if youre listening to your album and think, "You know I always wanted that vocal turned down a little there, that guitar part needs to be turned up a little bit here..", you're stuck because the studio doesn't archive any of the recording session. If youre lucky and are signed to a big enough record label, the label may purchase the multi-track sessions, but usually nobody does because the labels copyrights are for that final product that gets released and thats all they care about preserving. You can be assured the studio regularly wipes its client sessions from its drives, and will definitely erase and reuse that 2" tape for the next client that comes in (that stuff is NOT cheap).
Ok I feel the need to chime in here. I get so frustrated when developers throw their hands in the air and say "it can't be done"!
While technically the information supplied in this forum is correct it's very traditional thinking. My day job involves doing the impossible.
So here's the strategy for building IWD2:EE
Keep in mind that this might not be financially viable, I have no idea what the technical ability of the beam dog team is (and trust me you need some lateral thinking to get the task I'm outlining done).
Presumably IWD2 used an Infinity Engine base to start from. Presumably the IE code is readable given what I see modders doing (I've not looked into this, but it is apparent that there's some form of human readable code or modders would have a much harder time doing the stuff I've seen them do).
Given these 2 facts there's a gap in the middle. So close the gap...
How would you do this you might ask. Simple either implement the missing bits if they are simple or start reverse engineering IWD2 binaries to figure out what the missing bits did.
How long would this process take? Less time than it took to make the original IWD2 and more time than it would take to make an EE version of the game if you had the source code.
Further there's the fact that compilers only use set patterns to generate assembly, optimizations can make things a little more interesting. When you spent enough time in the trenches you learn to spot these patterns and it's not as hard as it might seem at first.
I get annoyed when people say things are impossible, because they can't do it. Then again, maybe I should shut up, since that's what keeps me employed...
So it's not impossible to build IWD2:EE, it might be infeasible to do so due to financial constraints. I suggest that if fans wants it badly enough they start a go fund me page or something to raise as much money as they can to see if that can get a project like this off the ground. At $20 per license I doubt the numbers would ever stack up.
Also before someone chimes in and tells me that I don't know what I'm talking about, this is the kind of stuff I do in my day job. I have lots of experience around this.
100% agree. Pisses me off that they won't do IWD2:EE because of this.
Comments
And don't forget, the IE+ engine has been migrated to 64-bits, so you'd have to update the decompiled IWD2 code to 64-bits while integrating it to the IE+ engine.
The easiest path to IWD2:EE would likely be porting the *content* to the IE+ engine, i.e., the AD&D 2E rules (w/some Player's Option additions).
I'll make another concession here, but again it's not a read block. Game devs aren't known for writing well structured and maintainable code. So the possibility exists that you'd need someone who can figure out obfuscated code. Not a huge issues but takes a bit more time. I'm not talking about code that's run through an obfuscator since there's known techniques for dealing with code like that. I'm talking about stuff that gets obfuscated during the course of writing code, fixing bugs and shoe horning features in. Now don't get me wrong I'm not dumping on game devs here, they usually have time pressure so I understand why things end up this way. I've also seen this more times than I care for in the "real dev world", but again nothing that can't be dealt with.
I said I was done ranting ;(
Also I need to state for the record that none of the stuff I'm talking about is rocket science, most devs are just scared of by it because they don't know where to begin. I know hackers who reverse code all the time and mess with good developers code, those same hackers can't code worth a damn. You don't need to be a genius to do this stuff, it's just a bit different. I really wish more devs would take an interest in this stuff since the security landscape would look a whole lot different if that was the case. If you consider that the buffer overrun is still fundamentally the most common type of attack (I'm not talking specifically your stock standard buffer overrun attack, but a variation on the concept, eg heap spraying).
I really should stop reading forums... I'm going back to sailing my boat now...
Its kinda like being in a band and recording an album at a professional studio. Unless the band/record label goes in and specifically pays for a copy of the digital song sessions, or the tape they are using to record it, all you walk out with at the end of the day are copies of the stereo masters of the final mixes you did. AKA that actual material that is going on the album. Meaning 10 years down the line, if youre listening to your album and think, "You know I always wanted that vocal turned down a little there, that guitar part needs to be turned up a little bit here..", you're stuck because the studio doesn't archive any of the recording session. If youre lucky and are signed to a big enough record label, the label may purchase the multi-track sessions, but usually nobody does because the labels copyrights are for that final product that gets released and thats all they care about preserving. You can be assured the studio regularly wipes its client sessions from its drives, and will definitely erase and reuse that 2" tape for the next client that comes in (that stuff is NOT cheap).
100% agree. Pisses me off that they won't do IWD2:EE because of this.