Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
DooM_RO

Ion Fury, a new Build Engine game out now.

Recommended Posts

EDuke32 is not distributed with IONFURY.GRP.

Share this post


Link to post

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

Share this post


Link to post
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?

Share this post


Link to post
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.

 

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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...

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
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.

Share this post


Link to post
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.

 

Share this post


Link to post
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 by ketmar

Share this post


Link to post
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:

 

 

Share this post


Link to post

Or this one:

 

 

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

 

 

Edited by seed : Too harsh.

Share this post


Link to post

I think it's distasteful to call that rape. 

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post

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.

 

Share this post


Link to post

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. 

 

Share this post


Link to post

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.

 

 

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×