Ion Fury, a new Build Engine game out now.

[kristus]

Probably nothing

[Gez]

EDuke32 is not distributed with IONFURY.GRP.

[VGA]

Did they program Ion Fury in a way that you are able to use eduke32 builds for ... perpetual updates? Forever?

[Jon]

5 hours ago, seed said:

I wonder though, since IF is based on eduke32, what does it have as a bonus that eduke doesn't?

 

The game content?

[Master O]

5 hours ago, Gez said:

EDuke32 is not distributed with IONFURY.GRP.

 

And accordingly, Ion Fury can be purchased at https://store.steampowered.com/app/562860/Ion_Fury/, https://www.gog.com/game/ion_fury, or http://www.ionfury.com/.

[ReaperAA]

6 hours ago, VGA said:

Did they program Ion Fury in a way that you are able to use eduke32 builds for ... perpetual updates? Forever?

 

Yes they intend to do that. Infact the Fury.exe (which is the executable of Ion Fury) is just a modified Eduke32. From what I read, regular Eduke32 builds CAN run Ion Fury but the menus will have some anomalies (which the devs intend to fix).

 

However there is atleast one IF specific Eduke32 build (posted by a user named LeoD in Duke4 forums) that can handle the menus perfectly as well. This was the build I posted earlier here on this thread.

 

Quote

If anyone is having performance issues with IF, try using this build of Eduke32 to see if performance improves or not.

 

[Gokuma]

This is like some Bring Your Own Iwad business, except it's .grp files.

[geo]

Are modders already working on Duke Forever to make an Ion Fury / Ion Maiden TC?

[Xaser]

Something worth noting here is that the lead developer for both Ion Fury and EDuke32 is the same guy (TerminX), so it make sense that the engine's the same under the hood.

[ketmar]

IF binary is just a special build of EDuke32. you can do that too with "make FURY=1". it excludes polymer (it doesn't work good anyway -- single-digit FPS even on the first scene), and some other things not needed in IF. or, you can simply use a "full" EDuke32 build, but you'll get some small visual problems in menus then (some extra menu items, so menus are vertically bigger, and sometimes doesn't scroll properly), but it is a minor thing, and doesn't affect gameplay. at least this is what i understood, and confirmed by experiments. i am using "fury build" (with FURY=1) to play the game, though.

[Doom64hunter]

Ion Fury's binary is compiled with the "STANDALONE" flag, which does remove certain Duke3D-specific behavior. Therefore the gameplay does have minor differences if one uses the regular eduke32 synthesis builds.

 

However, fury.exe is built from the exact same codebase as eduke32.exe. The only differences stem from what compile-time options the binary has been built with.

If you want to build eduke32 yourself, here's the instructions on how to do so: https://wiki.eduke32.com/wiki/Building_EDuke32_on_Windows

(Linux and MacOS instructions are linked from that page as well)

 

And like ketmar said above, you'll need to run the makefile with:

make FURY=1

which enables all compile options with which fury.exe have been produced.

[Graf Zahl]

Funny thing that this Duke3D specific stuff is only guarded by #ifdef's and not by a runtime flag, that'd allow switching it off with a standard EDuke32 build as well.

 

Regarding the game itself, I have just started playing, one thing that struck me immediately is the excessively colorful palette, almost causing sensory overload. Let's see how that develops.

 

Aside from that, it surely suffers from the typical EDuke32 problems, most notably a very uneven frame rate with constant hiccups, just ten times amplified compared to Duke 3D itself. That engine is in dire need of some serious optimization, but from looking at the source code I'd say that will be one gargantuan effort...

[Doom64hunter]

38 minutes ago, Graf Zahl said:

Funny thing that this Duke3D specific stuff is only guarded by #ifdef's and not by a runtime flag, that'd allow switching it off with a standard EDuke32 build as well.

There actually is a FURY runtime flag that is set to 1 if eduke32 loads the Ion Fury GRP, and it does disable certain other Duke behaviors like shrinking for instance.

 

The EDUKE32_STANDALONE compile-time flag was perhaps added at an earlier point, also in case someone else wanted to build their game ontop of Duke3D's branch of Build.

[seed]

1 hour ago, Graf Zahl said:

That engine is in dire need of some serious optimization, but from looking at the source code I'd say that will be one gargantuan effort...

 

I'm now curious since you looked at the code, is eduke32 a hideous codebase?

 

And how much of its code is bad? And what?

[Graf Zahl]

1 hour ago, Doom64hunter said:

There actually is a FURY runtime flag that is set to 1 if eduke32 loads the Ion Fury GRP, and it does disable certain other Duke behaviors like shrinking for instance.

 

The EDUKE32_STANDALONE compile-time flag was perhaps added at an earlier point, also in case someone else wanted to build their game ontop of Duke3D's branch of Build.

 

The FURY flag doesn't cover all of what EDUKE32_STANDALONE covers, though.

 

27 minutes ago, seed said:

 

I'm now curious since you looked at the code, is eduke32 a hideous codebase?

 

And how much of its code is bad? And what? 

 

It's going to be a long story to explain, you can find parts of it at one thread on the GZDoom forums.

This has a lot to do with the history of the code, Duke Nukem 3D consists of two initially separate code bases - the Build engine and the game code.

A lot has already been said about Ken Silverman's coding style - calling it obtuse would be somewhat of an understatement. The code is full of cryptically named variables, poor data organization and generally the engine has been developed very much with an assembly language mindset, i.e. nothing was made editing friendly, everything was solely optimized for the machine. That makes the engine code look very ugly and hard to understand because it's all numbers and strange variable names, but few symbolic constants that might help the person reading the code.

 

The Duke Nukem code had to work with this messy code but ultimately didn't really fare better - it made most of the same mistakes all over again, when I had a look at their CON scipt parser I couldn't really believe how crappy it is - although the language's syntax should have been a good indicator for what to expect here. In short, the game code looks quickly hacked together by some mediocre programmer (of course that's easy to say with 23 years of hindsight, in the mid 90's such a programming mindset was quite common.)

 

This very much contrasts Doom's source which went out of its way to have well named variables and a clean code structure that overall makes sense.

 

So, here we now have a source port of such a game that has been in development for over 10 years, but the one thing that was never done was any kind of serious refactoring. New features were just tacked onto the existing structure which ultimately results in code now that just amplifies those inherited problems even more.

 

Their entire low level play engine is still a single source file 400kb long with 13000 lines - their renderer is also all a single file with 9500 lines - and this is the core of the entire game, the two most essential files that drive everything.

I doubt that even a person who knows the code will be able to profile it and eliminate the bottlenecks because there's also no clean separation between high level data processing and low level render data generation, it's all one process that's being duplicated for countless cases down to the lowest level.

The final problem is not the code but their release schedule. EDuke32 does not have dedicated releases, just daily builds directly facing the end user. Start a round of larger changes and the official download will point to a broken executable.

 

That's simply not a situation conductive to breaking some code for longer periods of time. Big refactorings need quite a bit of testing to find and fix all those inevitable problems that come up. None of the big code replacements I made for both ZDoom and GZDoom could go right to production - they first needed quite a bit of internal testing so that when they got released only a few minor things remained.

 

[seed]

8 minutes ago, Graf Zahl said:

The final problem is not the code but their release schedule. EDuke32 does not have dedicated releases, just daily builds directly facing the end user. Start a round of larger changes and the official download will point to a broken executable.

 

That's something I noticed long ago on the website as well, there's only various builds available. I don't think I've ever seen a stable version number, just builds and more builds. But the quality at least doesn't seem to indicate that it's plain beta, unstable executables, from my experience they've worked quite well. Or I've just been lucky not to run into a crappy one.

 

12 minutes ago, Graf Zahl said:

The Duke Nukem code had to work with this messy code but ultimately didn't really fare better - it made most of the same mistakes all over again, when I had a look at their CON scipt parser I couldn't really believe how crappy it is - although the language's syntax should have been a good indicator for what to expect here. In short, the game code looks quickly hacked together by some mediocre programmer (of course that's easy to say with 23 years of hindsight, in the mid 90's such a programming mindset was quite common.)

 

So that's why people referred to the code as being held together by duct tape. I wonder if it isn't one of the main reasons why all Build engine games are so glitchy.

 

Did you take a look at the code of the Blood ports too? I'd like to hear how those codebases are compared to DN3D's, especially since they're both reverse-engineered due to the lack of source code (GDX uses some alpha code though). NBlood's is barely commented based on what I've seen, so apart from this.

[Graf Zahl]

1 hour ago, seed said:

 

That's something I noticed long ago on the website as well, there's only various builds available. I don't think I've ever seen a stable version number, just builds and more builds. But the quality at least doesn't seem to indicate that it's plain beta, unstable executables, from my experience they've worked quite well. Or I've just been lucky not to run into a crappy one.

 

From what I heard it did happen on occasion. However, don't forget that the lack of refactoring also means less risk of temporary instability - of course at the price of long term viability. The fact that they have never been able to address these performance issues I mentioned speaks volumes.

 

 

1 hour ago, seed said:

 

 

So that's why people referred to the code as being held together by duct tape. I wonder if it isn't one of the main reasons why all Build engine games are so glitchy.

 

The reason for that is that the game developers got the engine itself only as binaries to be linked with their game, so they never had the chance to fix the problems. And it is well known how glitchy the engine is, I have once seen a Duke Nukem 3D "speedrun" - this was not playing the game but abusing the engine's bugs from start to finish.

 

 

1 hour ago, seed said:

 

Did you take a look at the code of the Blood ports too? I'd like to hear how those codebases are compared to DN3D's, especially since they're both reverse-engineered due to the lack of source code (GDX uses some alpha code though). NBlood's is barely commented based on what I've seen, so apart from this. 

 

Of course being reverse-engineered will not show the true quality of the original code - what we cannot deduce is how their source was organized or how they named their variables or if they used symbolic constants instead of raw numbers which is the norm for Build itself.

That said, the NBlood source looks a lot more structured than any of the games derived from Duke Nukem.

 

[ketmar]

5 hours ago, seed said:

Did you take a look at the code of the Blood ports too? I'd like to hear how those codebases are compared to DN3D's

let me quote this little gem from the leaked blood alpha source code.

 

p.s.: programmers can read this too, this is not the source code, so no licence troubles attached. ;-)

Edited September 1, 2019 by ketmar

[Graf Zahl]

That was a truly enlightening trip into history. Thanks for sharing it.

 

[boris]

4 hours ago, Graf Zahl said:

The reason for that is that the game developers got the engine itself only as binaries to be linked with their game, so they never had the chance to fix the problems. And it is well known how glitchy the engine is, I have once seen a Duke Nukem 3D "speedrun" - this was not playing the game but abusing the engine's bugs from start to finish.

 

This one, probably:

 

 

[seed]

Or this one:

 

 

I don't know if I'm being biased or something, but Blood feels more legit than this...

 

 

Edited September 1, 2019 by seed : Too harsh.

[Jon]

I think it's distasteful to call that rape. 

[seed]

4 minutes ago, Jon said:

I think it's distasteful to call that rape. 

 

I didn't mean to be harsh, sorry if it came out that way (poor choice of words I guess). But it definitely doesn't look good either. Sure, Blood's not a huge improvement but it looks more like actually playing the game rather than plainly abusing it, at least on a surface level.

[Szymanski]

9 hours ago, Graf Zahl said:

Aside from that, it surely suffers from the typical EDuke32 problems, most notably a very uneven frame rate with constant hiccups, just ten times amplified compared to Duke 3D itself. That engine is in dire need of some serious optimization, but from looking at the source code I'd say that will be one gargantuan effort...

Was this port any better? http://fabiensanglard.net/duke3d/chocolate_duke_nukem_3D.php

[Graf Zahl]

It's comparing apples with oranges. EDuke32 uses an OpenGL renderer, this is merely the original software renderer in a cleaned up form.

From the looks of it the main problems with EDuke32 have to do with hardware resources like textures getting in the way of the high tic rate.

 

[Taurus Daggerknight]

My thoughts on the game: 

 

I've been playing it since its early access phase. It's nice, I love the atmosphere, the soundtrack kicks ass, and the guns sound nice and punchy. I'm also a huge fan of the protagonist's design, being a female who looks ready to kick ass without needing to be overly-sexy or trying to hard to NOT be distinctly female. 

 

... however....

 

I really dislike the enemy roster. I don't mind hitscanners per say, but the fact that near everything is a hitscanner capable of SNIPING you from dark sections halfway across the map, at times when you don't really have a suitable sniping weapon of your own (much less as cope), makes an already annoying horde downright irritating. what is with placing already hard to see enemies off in super distant, pitch black crevices, from which they can somehow land accurate shots using -shotguns- and -smg's- ?  

 

This is made even more infuriating by the whole "enemies teleporting in". It is incredibly frustrating to hit a switch, only to turn around and suddenly be ambushed by a room full of enemies that had no logical way of getting there (not even a teleportation effect... ). They really just appear out of thin air, in places you already cleared. Worse still is when you suddenly get jumped by a couple of those rocket spamming flying things in a super tight space. We're talking Warhammer 40,000 bolter gun rate of fire here, not the Revenant's rockets from Doom. In fact, flying enemies in general are a huge pain, virtually impossible to hit without the pistols auto-aim secondary fire.

 

Enemy design also falls a bit short. During the Early Access period, it was fine, as I assumed we were just facing the basic level mooks. Thing is; those are about 90% of what you'll face. There is almost nothing distinctive about them, and meanwhile the spider bots and one of the flying things look obviously like kitbashes of each other's sprites. This is made a little worse by the shockingly dull, place-holder looking tracer visuals for all gunfire. It mostly looks like just bland dotted lines, rather than even trying to look like a blazing projectile the way literally every other FPS handles it. Which is to say; enemies themselves neither look distinctive, nor does their weapon fire bring energy to the fight. 

 

The projectile VFX issue sort of extends to the graphics in general. I understand that they were going for a full retro feel, but at this point, I've seen Doom mods that look visually more distinctive and awe inspiring without sacrificing the overall aesthetic. Especially considering Duke Nukem 3D World Tour's lighting tweaks, I can't help but wonder why Ion Fury chooses to look as rough as it does in some places. I love the aesthetic, and some of the rooms do look pretty neat, but in most cases I can't shake the feeling that we've seen better uses of both Build, and even Doom engines. 

 

Finally; the weapon set. I like how punchy the guns are, and I like the look of them. However, there are too few weapons, and there is a bit of overlap among the ones that are there. The Bowling Bomb and Cluster Puck functionally do a similar thing (grenade toss), as do the SMG and Chain gun, both of which have too little ammo. The fact that the SMG's burning effect does not stun enemies makes it fairly useless as well. Gee, great, enemy is on fire. Too bad he doesn't seem to care and just keeps shooting anyhow.... I don't know, I think I'd have liked to see more weapons that catered to a wider range of tactical situations. A rocket launcher would be welcome, maybe an actual flamethrower too. And seriously; ammo is way too limited for each weapon.  

 

The thing is; I really enjoyed the Early Access build. I loved the atmosphere, and I liked how punchy the guns felt. But the end result does not seem much improved over that build, and honestly feels incomplete in a lot of ways. Maybe I was expecting something that was never promised, but this just fell short for me after playing years of superior Doom mods and other retro FPS titles. I expected more out of the final game. 

 

[Graf Zahl]

You know what? I had the same feeling about the enemies when replaying Duke Nukem 3D for the first time in years recently. I found the enemy AI underwhelming and annoying and considering that Ion Fury uses the same engine your assessment doesn't really come as a surprise.

 

Doom's AI may be as primitive as it may come, but for some reason it really hits the sweet spot for dynamic and enjoyable gameplay.

 

 

[VGA]

Duke Nukem World Tour sometimes looks stunning. Or eduke32 with the converter mod and the Polymer renderer.

[Jon]

I really feel this owes a lot to Action Doom 2 of all games

[amackert]

Pretty late to the party on this one, but I picked it up yesterday and put a couple hours into it. Oh man, it's so good! I put it off for a while because I'm not the biggest fan of the hit-scan focus so many Build games seem to go by. In Iron Fury though, it really feels like you have a lot more freedom to move around and dodge and weave, similar to Doom. Combat feels satisfying, the levels are insanely detailed and complex, and the nods to '90s era PC titles is great. Though, a few levels in, I'm starting to regret playing the game on the fourth difficulty. Enemies do tons of damage and my ammo is ridiculously tight. Might switch it down to the third difficulty and start over. Regardless, I'm impressed.