He was the guy who worked on the Halo 3 main menu.

so where is the programming background to support the statement?

I'm pretty sure Mootjuh meant the Halo 3 UI for CE.

Yup that.

the statement =

The custom Halo engine and the Halo 3 UI for CE are 2 separate things. Mangenkyo did not build that engine.

Here is the original thread.

http://forum.halomaps.org/index.cfm%3Fpage=topic&topicID=44621
Edited by Mootjuh on Dec 29, 2015 at 07:53 AM

No, they phased out Unrealscript in UE3. You've either got Blueprints and C++ now. I got a coupon for a 'Learn C++ With Unreal Engine 4' course on Udemy to use, but even looking at UE4's source code is all kinds of terrifying.

The main problem with Blueprints is that you're taking something like a 10-fold performance hit compared to native code, so even though you're welcome to go write all the complex game logic you want, it's gonna start chugging fast.

There's a 3rd-party UnrealScript-like scripting language currently in closed beta, called SkookumScript, which looks like it might be of use, especially as it's specifically meant for scripting game logic and apparently executes at near-native speeds, but I've yet to give it a whirl.

you still misunderstand.

I ask if there's anything other than secondhand hearsay to backup what he said in the quote.

beaucephal, where did you find that "10-fold performance hit" related to blueprints information? I have some very complex blueprints, and they all run perfectly fine on my medium - high-end'ish PC.

I get the impression blueprints are designed to be higher level than unrealscript.


e: I think he meant relative to just modifying the source. A performance hit is kind of a given in any scripting language.
Edited by BKTiel on Dec 29, 2015 at 08:31 AM

It was a ballpark figure thrown around on the Unreal Engine forums. Obviously YMMV, but most Unreal Engine 4 games I've played run like absolute turd if they use Blueprint exclusively. That may simply be bad optimisation on the dev's part though.

He has since switched to C++/OpenGL, as of June 2015.

It will likely not see the light of day as a functionally complete or playable engine for a few more years, if ever.

Then he will most likely travel the road I did, with the Ficus engine.
It's a brilliant learning experience, but oh boy, will he regret using OpenGL.

As someone who codes almost exclusively in blueprints, I can't exactly agree with this statement - I've only had one minor hickup due to them (probably due to bad code somewhere), but overall I have some VERY complex blueprints in the game I've been working on.

I'm not entirely disagreeing with the fact that yes, native code DOES go faster, but blueprints aren't really that slow as some people make them out to be. Many of Epic's examples, such as Tappy Chicken, are coded entirely inside of blueprints. I've also been working on a mobile game for the past couple of months entirely in blueprints and it runs fine on devices.

Epic has talked about in a future update they will also be working on converting blueprints into native C++ code when you cook/compile, so in the future it probably won't even matter or have an impact at all.

Oh.

Oh wow. Now that would be a thing of beauty.

Thing with blueprints, even with the 10 fold performance hit, it does not make it slow. You can script whole games in blueprints and still be fine. Once you get into game dev for lower end platform it might become an issue. The difference in performance will depend how many stuff you've set up on tick mostly, and even then the difference is usually not more than a couple of nanoseconds.

Either way, CPU is usually not your bottleneck. The graphics are. For example everything I have atm goves me a 4ms code latency and 40ms gfx latency. Meaning the CPU has to wait on the GPU. Blueprints are really fine to use. The issue is when you start to want to edit the source code to create awesome stuff.

Nobody likes Java.
There

What graphics card do you even have...?

He is using the Leerdammer 3000 series.

HD7670 and the scene is pretty heavy. Getting 30FPS at 720p Epic settings.
And that's when I turn static lighting into dynamic lighting and all hell breaks lose.

Funny thing is it's waaaay below the recommended specs.

Either way, point is gfx are usually more demanding than processing power so you should be fine assuming your end user has a balanced PC that where one is not bottlenecking the other.

Mind sending us some screenshots of the scene? Am curious.

I do mind.
Edited by Mootjuh on Dec 30, 2015 at 06:13 AM

Typical Dutch mentality :-)

now do the ai
Edited by Halonimator on Dec 30, 2015 at 08:40 PM

List out the parameters you want and I'll do it.

the actor and actor variant with C# or C++... it is posible to make it with unity 5?
Edited by Halonimator on Dec 30, 2015 at 08:48 PM

I meant the things you want it to be able to do, not how you want it made.

Mookz, unfortunately that screenshot isn't high-res enough to be legible.
What exactly are you trying to do though? You just want to alter your camera's "zoom factor"?

That can be done by adjusting the proper FPS Character's camera values.
Something like the below, note that it obviously isn't connected up, but that would give you a gradual zoom. If you want an instant-zoom adjustment, just get rid of the timeline.
Oh and ignore the global time dilations, unless you want to do some crazy Matrix-style stuff :-)

I have a node headache.

Why are you building off of UT? Building off just the base UE4 might save you a lot of trouble down the road. Theres a few additional steps to getting weapons working of course, but its really not that difficult :)

Agreed. It would also allow more freedom when working with some stuff, and I'd assume most of what you have already would transfer comfortably, though I believe you'd need to build some of the underlying framework from scratch, but I don't think it'd be that bad.


Welcome to unreal editor. Even more fun than the slate material editor.

Neat. You can remake that I'm sure. Also, if the first map that comes out of your project isn't bloodgulch, I'm not playing it. That's a lie. Don't make a bloodgulch to start with, I want to move away from them. And don't include the whole ripping assets easily thing.

MS probz gonna pull the plug when using ripped assets anyway, unless you ask nicely.

Better to use ripped assets for testing, than have no assets for testing. #2016Wisdom

Yo Mookz,

Just so you know, doing a cone trace isn't possible out of the box in UE4. You'll need to mimic it by doing several sphere traces that gradually increase in radius. An alternative would be using multiple line traces at different angles.

Your line trace logic looks correct at a glance, assuming "current look rot" is actually a weird name for your "forward direction vector". Try setting Draw Debug Type to something like "for duration" instead of just for one frame, it should give you a better idea what your trace is doing. If the trace itself is going to the right place, make sure the collision of your enemy is set up correctly to block or overlap the visibility trace channel.