
Why C++ for Unreal 4 - zschoche
https://forums.unrealengine.com/showthread.php?2574-Why-C-for-Unreal-4&p=16252&viewfull=1#post16252
======
flohofwoe
We've also been there done that (about 10 years ago though), we had a very
powerful scripting approach integrated into our game engine which gave direct
access to game play systems in order to let our level and game designers build
scripted behaviour into the game. In the end we ended up with a terribly huge
mess of script code (I think it was about a third of the actual C/C++ code)
and the majority of the per-frame performance-budget was lost somewhere in
this scripted mess. The game sometimes suddencly crawled to a halt when some
crazy scripting construct was called, and we had a lot of trouble getting
stuff into a shippable state until the gold-master milestone (this is the
game: [http://www.metacritic.com/game/pc/project-
nomads](http://www.metacritic.com/game/pc/project-nomads)).

The main problem with scripting layers is that you are basically handing
programming tasks over to team members who's job is not to solve programming
tasks, and thus getting a lot of beginner's code quality and performance
problems which are almost impossible to debug and profile (unless you have a
few top-notch coders in the game- and level-design teams).

And then there will be definitely those "creative workarounds" to get
something done which neither the engine nor the scripting layer was designed
for, which make entertaining horror stories the programmers tell the new hires
when they inevitable ask why your engine doesn't have scripting ;)

A better approach is to give the level designers simple, pre-programmed,
combinable high-level building blocks (AI behaviours, actions, triggers, etc),
and let them customize a level (as in game area) with this. But never build
the entire game logic with such an approach! With this, stuff can still be
fucked up, but at least the performance-sensitive stuff can be implemented by
the programming team, and it's much easier to debug and maintain.

[edit: typos]

~~~
greggman
The biggest advantage of scripting for me has been

1\. Co-routines

Co-routines (co-operative multi-tasking?) mean you can do stuff like

    
    
        while (isWalking()) {
          advance();
          yield();
        }
        
    

This is effectively 'yield' from Python, C#, etc.. You can implement this in
C++ by swapping stacks and calling setjmp but there's usually issues.

2\. Iteration time

You can usually swap script code live. This project aims to fix that for C++
though I'm a little skeptical it can stay robust

[https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledC...](https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus)

~~~
VikingCoder
I've been using threads to do co-operative multi-tasking, for a while now.

Every place that I'm tempted to write an event-driven finite state machine, or
something similar, I spawn a thread instead. I get to write synchronous code,
which feels much more natural to me.

For instance my actor, running in a thread, calls a function like advance().
That drops data into an object, and wakes up the main thread, and blocks.

The next time the main thread wants to give processing time to the actor, it
describes the world into the same shared object, waked up the actor's thread,
and blocks.

Doing a switch like this dozens or even hundreds of times per second seems to
work pretty well, especially if the main thread only gives execution to the
actor thread when it needs to - inputs have changed, etc.

For my use cases, it radically simplifies my code, and I have a small number
of different inputs to handle, so it has been scaling well.

~~~
srean
That is precisely the beauty of coroutines: your code can look like threaded
code but you can get the performance of an event-loop. Put another way, with
coroutines you get most of the advantages of an event loop but very few of its
disadvantages. (You get concurrency only, not parallelism, well this is almost
true). For cooperative multi-tasking, threads are unnecessarily resource
hungry and wasteful. They hoard resources although most of the time they are
doing nothing just waiting. This is usually fine if you think yours is the
only application that should be running on the hardware at that time, but
typically you want to share the hardware with others.

Remember not everybody has the luxury of working on a system where you can
spawn 10,000 threads without breaking a sweat.

However this territory of literally hundreds of thousands of programmed agents
participating in a game does not seem to be very populated. Perhaps part of
the reason is that very few languages had efficient (this eliminates stack
copying), scalable and portable support of coroutines. This is starting to
change, but not as fast as I would like.

I think C is to be blamed for the long under appreciated status of coroutines.
It is one abstraction that C left out, although the VM C had as its execution
model (the PDP) had excellent support for coroutines at the instruction level.
C exported pretty much every abstraction of the underlying instruction set,
but not coroutines.

EDIT: @VikingCoder Replying here as HN wouldnt allow me to respond till some
time has past. Yes I have looked at asio although just scratched the surface.
It looks very interesting, as far as I know they are not threads though (which
is a good thing), they use macro and template metaprogramming trickery to turn
producer-consumers into one big switch case. If you interested in coroutines
and seamless interaction with C++ I can recommend [http://felix-
lang.org](http://felix-lang.org)

~~~
munificent
> C exported pretty much every abstraction of the underlying instruction set,
> but not coroutines.

My hunch is that the designers of C would have said "goto" and "switch" cover
the use case where you have a bunch of peer chunks of code that you want to
freely bounce between.

Remember, at the time function calls were considered expensive, so not support
full coroutines across function call boundaries may not have been on their
minds as much.

~~~
srean
Indeed, and thanks for the excellent commentary on coroutines, awaiting the
blog post. I think another fact played into their decision: coroutines do not
specify how they are to be scheduled, that leaves room for arbitrary policies.
Not that C shied away from keeping things undefined.

------
octo_t
The phrase

> 'What starts out as a sandbox full of toys eventually grows into a desert of
> complexity and duplication.'

is beautiful and is a pattern I've seen multiple times before. Its not feature
creep per-se, but more something a bit more insidious in software development.

~~~
simias
That's a good lessons for people wanting to create a new languages too. One of
the reasons C++ was successful in the first place is that it needs almost no
glue to interface with C code. Contrast that with all the languages providing
a more or less cumbersome FFI.

Rust for instance looks very promising but you still have to go through the
tedious task of redeclaring all the prototypes of the C functions before you
call them, it cannot directly parse C headers (as far as I know). That makes
writing hybrid code (for instance incrementally porting code from C into Rust)
much more difficult and error prone than they need to be.

~~~
kibwen
Actually, one of the first tools to appear in the Rust ecosystem was a port of
the "bindgen" program written for the Clay language, which has been solving
the problem of parsing C headers for years now:

[https://github.com/crabtw/rust-bindgen/](https://github.com/crabtw/rust-
bindgen/)

There are also long-term plans for adopting this into the compiler itself:

[https://github.com/mozilla/rust/issues/2124](https://github.com/mozilla/rust/issues/2124)

~~~
simias
Ah, thank you, I knew I saw something like that when I looked into rust a
while back, but there was no mention of it in the Rust FFI guide[1]. It should
definitely be included in the compiler at some point, it's a vital feature
IMO.

[1] [http://static.rust-lang.org/doc/master/guide-
ffi.html](http://static.rust-lang.org/doc/master/guide-ffi.html)

------
xedarius
I developed two titles with the Unreal Engine and whilst initially
UnrealScript seems like an advantage it very very quickly becomes problematic.
My favorite being the dependency of the C++ code on the script and the script
on the C++, so if you're not careful you can end up being completely unable to
do a build.

As much effort as they put into the IDE it would always play second fiddle to
Visual Studio. When I left there was no way to remote debug unreal script on
the target device (this may not be the case now).

I know that all of the guys I worked with in the studio would welcome pure C++
approach. The only real losers here are mod makers who will have a higher
entrance bar.

~~~
CmonDev
They could also use C# instead of UnrealScript on top of C++. This way you
would be able to leverage the Visual Studio while getting one of the best
languages. It would make Unity3d guys welcome once they need something better
as well.

PS: I like the BluePrint though.

~~~
kevingadd
To second what scott_s said, you'd have a huge interop layer. The fact that C#
has a closer match to C++ types and primitives doesn't mean you have no
interop. Unity has a huge surface area between the C++ parts of the engine and
the C# parts of the engine; a ton of work goes into maintaining that, and it
complicates porting to new target platforms like the web (can't just feed
everything through emscripten).

~~~
azakai
Yes, C# and other .NET languages are nice, but the open source implementation
(Mono) ends up being difficult to port to novel platforms due to a combination
of technical and legal issues.

------
HeXetic
It's important to note that what is being talked about in this post is not,
"why we wrote the Unreal engine in C++", because it already _was_ in C++. Many
games, older Unreals included, had a separation between "code" and
"scripting", where stuff like animations, weapon firing, etc. was written in
scripts, in the belief that this would be easier to update as required vs. C
or C++ code.

Doom 3 and previous Unreal engines had scripting languages; even the first
moddable FPS engine, Quake, had a 'scripting language' of sorts -- Quake C, a
sort of subset of C. id software turned back to pure code with the Quake 4
engine, however, recognizing the mistake that introducing the overhead of
script-vs-code, and the limitations of scripts, outweighs any gains from being
"easier to edit".

~~~
angersock
Brief rant:

Quake 1 ran a virtual machine, which QuakeC compiled down to. Quake 2 ran
native code via DLLs. Quake 3 ran either VM code or native code--depending on
how clever you wanted to be, you _might_ need to break into the native code.

There wasn't some "mistake" about using scripts-vs-code, because they would
actually compile down to executable bytecode. This made it much easier to load
mods over the network if you needed to, and to port their tech to different
architectures.

idTech 1-3 internally were a lot more like VR operating systems than
scriptable game engines.

 _and the limitations of scripts, outweighs any gains from being "easier to
edit"_

Wrong, wrong, and wrong. The mod scene flourished back in the day
_specifically_ because it was so easy to bodge together mods in these
friendlier environments--especially in the Unreal series.

The place where scripting falls apart is in modern AAA games where way too
much stuff is expected of/exposed to designers, and then you end up with
gigantic sprawling piles of poor performance. A friend worked with a licensee
of the Unreal engine for a few games, and their script dispatch switch went on
for...well, let's just say that many good programmers lost many good hours in
those mines.

Scripting is a perfectly good tool, and one that makes sense until you start
doing crazy AAA stuff with it.

~~~
HeXetic
As a Doom 3 modder myself, I experienced considerable headaches juggling the
interplay between scripts and code, especially since so much stuff (like
firing a gun or moving around) spanned the two systems so inelegantly.

~~~
angersock
I think it was handled somewhat better in older engines.

Doom3 seemed a bit of an odd duck.

------
CyberShadow
There was a talk at last year's D conference how Remedy Games have used D as
their "scripting" language:

[http://dconf.org/talks/evans_1.html](http://dconf.org/talks/evans_1.html)

I wonder if some of the same points would apply here. The short version of the
talk is that D compiles much faster than C++, has limited C++ link
compatibility (e.g. classes, but not templates), and overall has nicer syntax
/ language features than using C++ directly. Metaprogramming / compile-time
introspection allow automatically serializing/deserializing data to allow
updating data structures without restarting the engine.

~~~
pjmlp
Yeah C++ compile times will be a pain until a module system gets done.

This is why I follow with high interest the work clang guys are doing for the
committee.

------
mccr8
These issues are all very similar to the difficulties with interaction between
JS and C++ in web browsers. A lot of engineering and specification effort has
been expended in browsers to improve these problems, on things like WebIDL
[1], codegenned bindings[2], JITs that understand some of the behavior of the
underlying C++ operations [3] and so forth, but for a game engine where you
aren't running potentially malicious code I can see that it would make a lot
more sense to just tell people to use C++ rather than expend that effort.

[1] [http://www.w3.org/TR/WebIDL/](http://www.w3.org/TR/WebIDL/)

[2] [http://jstenback.wordpress.com/2012/04/11/new-dom-
bindings/](http://jstenback.wordpress.com/2012/04/11/new-dom-bindings/)

[3]
[https://bugzilla.mozilla.org/show_bug.cgi?id=938294](https://bugzilla.mozilla.org/show_bug.cgi?id=938294)

------
beefsack
It will be interesting if any major game engines pop up using Rust as the core
language, or even Go. C++ has been the king of highly optimised game engines
for so long, I can't help but feel it has become so entrenched in the industry
that it will take something monumental to disrupt it.

~~~
mattgreenrocks
What's the appeal of Rust for gamedev?

~~~
bjz_
\- Fine grained control over allocation whilst maintaining memory safety
(stack, heap, RC, GC, or roll your own)

\- No null pointers (with an Option type that compiles down to a nullable
pointer)

\- Data race free concurrency

\- Zero cost abstractions

\- RAII and destructors

\- No exceptions

\- A modern, highly expressive type system

\- Generics that throw type errors at the call site, not deep in a template
expansion

\- True immutability (not `const`)

\- An excellent C FFI

\- Compiles to native code

\- You don't pay for what you don't use

\- Safe by default, but you can circumvent the safety checks if you know what
you are doing, and those places are clearly marked and easy to audit. Inline
assembly is supported.

\- Most safety is enforced statically, so you don't pay for it at run time.

~~~
mattgreenrocks
I was being a bit flippant when I posted, but I'm really impressed with the
list. I need to look into seeing where I can help on the compiler or runtime.

No exceptions is my only objection, but I know they're dubious for a systems
language.

~~~
bjz_
No worries, it was a good question! I would highly recommend hopping on the
IRC if you'd like some more information or have a chat. The community is very
active and friendly. You can see the list of channels here:
[http://static.rust-
lang.org/doc/master/index.html#external-r...](http://static.rust-
lang.org/doc/master/index.html#external-resources)

Regarding exceptions: whilst they can be be very useful, unfortunately a
significant number of large, performance sensitive C++ projects outlaw them
due to overhead and safety concerns (the semantics can become quite hairy when
mixed with destructors). The Rust developers felt that it was easier to forgo
them entirely.

~~~
deathanatos
> due to overhead

My understanding is that the old exception code called "SJLJ" (short for
setjmp, longjmp, which is what it was) _was_ slow. I think each try/catch
required hooks, and yes, it was.

The newer compilers generate something called "DWARF"; resources on it are
unfortunately scarce, but my understanding is that you don't pay anything in
speed for an exception until you throw one. (You do however pay a bit of
disk/memory for data about where try/catch handlers are, I think.)

> safety concerns (the semantics can become quite hairy when mixed with
> destructors)

I'm assuming that you shouldn't throw in a destructor.¹

This argument, to me, always needs more information attached to it, because by
itself it's meaningless. Assuming the alternative is returning either the
result, or an error code, you run into _exactly the same semantic issues_ ,
you're just handling them manually now. Is that better, and how?

In the manual case. If I assume I have some code that returns to me an error
code that I can't handle, I need to propagate that error up to a stack frame
that can. Thus, I begin to manually unwind the stack, during which, I destruct
things. If we're assuming destructors can throw², then I can potentially run
into the problem of having two errors: _now_ what do I do?

C++ isn't the only language here: C#, Python, and Java share the problem of
"What do you do in the face of multiple exceptions requiring propagation up
the stack?", though I think C++ is the only one that solves it by terminating
the program. I believe C# and Python just drop the original exception, and I
have no idea what Java does. Honestly, if things are that effed up, terminate
doesn't sound that bad to me. In practice in C++, most destructors can't/don't
throw. (Files are about the hairiest thing, since flushing a file to disk on
close _can_ fail: C++'s file classes will ignore failures there, which doesn't
exactly sit well with me. You can always flush it manually before closing, but
of course, if you do this during exception propagation and throw on failure,
you risk termination due to two exceptions.)

Even C has this, in that if you're propagating an integer error code up the
stack, and something goes wrong in a cleanup, you've got this problem. In C,
you're forced to choose, of course, including the choice of "ignore the
problem entirely".

That said, I'll add the answer for Rust here. (I've never used Rust, so
correct me if I'm wrong. I'm going abstract away the Rust-specific types,
however.) Rust, for a function returning T but that might fail, returns either
Optional<T> or a Result<T>-ish object, which is basically (T or ErrorObject).
Rust has strong typing, so if there's an error, you can't ignore it directly,
because you can't get at the result. And if you try, it terminates the "task".
Strong typing is the winner here. (This reminds me why I need to look into
Rust.)

¹It's not illegal to do so, but since destructors get called while an
exception unwinds the stack, you can potentially run into an exception causing
an exception. Two exceptions in C++ result in a termination of the program.

²If we're not, then exceptions are perfectly safe.

~~~
bjz_
Yeah, I will admit I am not an expert in exceptions, so I might have been
incorrect in my response. I'm sure there would be better people to talk to on
the #rust. Alternatively you could ask on the mailing list or /r/rust.

------
pjmlp
The PVS-Studio guys have a static analysis of the code quality

[http://www.viva64.com/en/b/0249/](http://www.viva64.com/en/b/0249/)

------
archagon
On the other hand, I feel that tools like Unity are successful precisely
_because_ they let you tinker with your game in a WYSIWYG kind of way. It's
really liberating to be able to work inside such a tight feedback loop, and
it's a little weird to see a modern game engine distancing itself from that
approach.

(But maybe I'm missing something. What exactly is the role of the Unreal
Editor in UE4? Is it mostly for things like graphics and sound?)

EDIT: OK, so apparently UE4 has something called Blueprints. I'm still not
exactly sure what they are, but people in the thread are saying that they're
superior to C# in Unity, and that they can even allow you to make a game
without knowing how to program. So why is Tim Sweeney saying that C++ is
replacing UnrealScript for gameplay code?

~~~
admiun
There's actually an interesting demo of the blueprints feature in the toolset:

[https://www.youtube.com/watch?v=9hwhH7upYFE#t=384](https://www.youtube.com/watch?v=9hwhH7upYFE#t=384)

------
nly
Maybe UnrealScript was just too damn complex. Having not used it, and just
Googled it, my first reaction was "this looks just like C++ anyway". What's
language features are there specificity catered for games? It doesn't seem
very DSLy

~~~
barrkel
It had synchronous-style code for handling animation logic, without needing
hundreds of threads.

It also had some clever ideas about replicating state across the network. You
want to run the simulation locally to reduce latency, but you also need it to
run elsewhere to have a consistent source of truth. So some state would be
calculated by the local simulation, but be updated when packets of truth
arrive. Member variables could be annotated according to how they were
replicated, IIRC.

------
pjmlp
The whole C# vs C++ discussion going on the forum shows how little current
generations understand of compiler design and language implementations, oh
well...

~~~
berkut
Exactly.

What's most distressing is people (as normal) are completely ignoring the
garbage collection overhead, which is mostly where the advantage of having
complete control is, in terms of micro-managing your memory allocation, e.g.
using slab allocators, memory pools, pre-allocation, etc.

C# code in theory (ignoring things like intrinsics support and inline asm) can
be as fast as C++ for tight loops, but in my experience (writing 2D/3D
software for the VFX industry) +85% of the time if you profile something,
it'll be the memory allocation which is killing things performance wise.

~~~
Pxtl
C# has support for stack-allocated "struct" objects that avoid the GC. They
have their limitations and gotchas, being somewhere between simple C structs
and C# classes, but they exist.

GC-based languages run games on many, many platforms. The problem, imho, is
that you have to leave 90% of the language features on the shelf when you're
doing your main loops in order to avoid triggering the GC.

The gaming industry is practically begging for a language like Rust.

~~~
ajanuary
I feel like I should point out that the stack is an implementation detail [1]

Though in this context it's relevant to point out pretty much any
implementation will stack allocate them, it's not accurate to say C# has stack
allocated objects.

[1]
[http://blogs.msdn.com/b/ericlippert/archive/2009/04/27/the-s...](http://blogs.msdn.com/b/ericlippert/archive/2009/04/27/the-
stack-is-an-implementation-detail.aspx)

~~~
Pxtl
Regardless, C# has a linguistic feature that provides objects with stack-like
performance and copy-by-value semantics familiar to C developers.

------
XorNot
I remember back when Descent 3 was being developed, the devs must've run
straight into this problem since pretty late in the development cycle they
suddenly dropped their script language for pure C++ libraries for scripting
levels.

------
danso
> _Developers seeking to take advantage of the engine 's native C++ features
> end up dividing their code unnaturally between the script world and the C++
> world, with significant development time lost in this Interop Hell._

Replace "C++" with "JavaScript/client-side processing" and "script" with
"server-side scripting" and I feel like this adequately describes web-
development.

~~~
pjmlp
You also need to add the dark magic tribal dance of making CSS/HTML/JavaScript
work in a coherent way across all target browsers in mobile, desktop, TV,
settop boxes and whatever else...

At least that is how it feels for guys like myself that lack designer skills.

~~~
darylteo
I've yet to meet a designer that can do the above. Its very much a black magic
regardless of who you are.

------
syncsynchalt
Inner Platform Effect: "the tendency of software architects to create a system
so customizable as to become a replica, and often a poor replica, of the
software development platform they are using" \-
[http://en.wikipedia.org/wiki/Inner_platform](http://en.wikipedia.org/wiki/Inner_platform)

Seems an appropriate term here.

------
leoc
The upshot is likely that a community-created Lua or JS binding will gain a
significant userbase.

~~~
CyberShadow
Note that you'll need a language capable of AOT compilation if you want to
target consoles which only run signed code (or use an interpreter, which will
be rather slow). JIT is not an option on those systems.

~~~
dkersten
The LuaJIT interpreter is surprisingly fast. Still not as fast as the JIT or
an AOT compiled language though...

~~~
NickPollard
His point though is that JITs (like LuaJIT) are often not allowed on consoles
for security reasons - they don't allow running of unsigned code. So LuaJIT
might not be an option.

~~~
dkersten
As myrmidon said, LuaJIT ships with a very fast interpreter.

What I was _trying_ to say is that, while its not as fast as JIT or AOT, it is
still extremely fast (many times faster than the reference Lua implementation
apparently).

------
kayoone
Unity runs well with a Scripting approach and for everybody where thats not
enough, you can still get the full source license. I think Unity did it quite
clever in that the engine itself is c/c++ and all the interfacing with the
engine is done through C#/Mono.

~~~
thefreeman
Unity caters to new game developers though. I'm not saying you can't make real
games with it, but I'd be surprised if it was used for AAA titles, and
definitely not as much as Unreal Engine.

Also, I found this comment from later in the thread really interesting about
how easy it is for hackers to abuse the reversibility of managed (.NET) code.
Granted, this could just be due to poor design on the developers part, but
giving hackers that kind of insight into the games design cannot be helping
anything.

 _So with that, This could be a unity issue, mono issue, or just the game
developers issue. For background reasons, I am a local memory hacker, tho the
reason I am here on UE is im teaching myself how to develop games not for
hacking purposes. The game im going to talk about is the only game I know that
is MP only and uses the unity engine. This game has one big problem when it
comes to hackers, what we do is simply edit the .net dll 's to manipulate the
game, no hooking, no debugging, no working out functions in assembly, it also
meant that we could reverse the source to pretty much 100% usable source -
this resulted in the end user being able to change things like the user id to
stop them being able to be banned. Un-Ban able hackers? its destroying this
game. _ [1]

[1] - [https://forums.unrealengine.com/showthread.php?2574-Why-C-
fo...](https://forums.unrealengine.com/showthread.php?2574-Why-C-for-
Unreal-4&p=16730&viewfull=1#post16730)

~~~
archagon
I think Unity also caters to indie developers with new game ideas, as well as
to rapid prototypers. (The two often overlap.) Would we have gotten games as
cool and varied as Receiver[1], Broforce[2] and Hearthstone with UE? I kinda
doubt it.

[1]
[http://store.steampowered.com/app/234190/](http://store.steampowered.com/app/234190/)

[2]
[http://store.steampowered.com/app/274190/](http://store.steampowered.com/app/274190/)

~~~
thefreeman
I completely agree and I don't mean to knock on indie developers or unity. I
just was trying to make the point that for UE's bread and butter market, this
is probably a good decision.

------
daenz
This was refreshing. I'm struggling with the same problem...I've embedded Lua
in my C++ engine for high-level scripting. Unfortunately, as my scenes became
more and more complex, I found myself struggling with representing the
inheritance hierarchies in Lua, as well as things like object ownership/gc
(resorting to passing around shared_ptrs in Lua userdatas). And for each new
data type, I had to write the same old C++ boilerplate to make it available in
Lua the way I needed to. The complexity is getting to be too much.

I think this article is going to push me to strip out the embedded Lua from
the engine and use plain old C++ as well. Great read!

~~~
djur
Embedded scripting languages seem to work best on what I'd call a 90/10 model.
Either your game is written in the scripting language inside a thin compiled
shell (to provide access to system routines and the occasional optimization),
or your game is written almost entirely in the host language and just
configured using scripts. So: 90% Lua, 10% C++ or vice versa, but not 50/50 or
the like.

In general, it seems to be a red flag if a single thread of logic runs back
and forth between host and scripting contexts.

~~~
yoklov
Alternatively, write most of it in C++ and allow it to be extended with
components written in script, ECS style.

Or something else.

Honestly, having too much scrip is very much a thing to try and avoid. Perf
(gc, etc), long term maintainability (usually no static types in script),
tooling (frequently no debuggers, profilers, or the ones that exist are low
quality), etc are all reasons for this.

If you're going to have 90% lua, you probably should be writing the game in
lua anyway...

------
golergka
Right now I sit through the second week of non-stop iOS crash logs of our
Unity game, which are opaque, unclear and mysterious for the most part, and I
can't agree more.

------
Guthur
From my limited experience of Unreal Script it was a pretty rough
implementation of a language, it really didn't seem to provide any real
benefits.

What I would have liked to see was better support for interactive development.
When I was playing with it I still had the edit/save/compile/run loop to see
my changes, that's not what I want. I use Common Lisp extensively and
appreciate the power of a REPL, it's available in many languages now. This
brings me to the next point of providing powerful reflection support so that I
can easily explore the state of the application, as well as better debugging
tools.

UnrealScript was just not a very good language implementation in my opinion.

So in my opinion removing it and exposing the C++ is a good thing. But not for
the same reasons that most are touting, I don't want to code in C++. But now
it should be a lot easier to build a reasonable Lisp on top of Unreal Engine
4, which is what I really want.

------
anoplus
A(programming) language gets very powerful by simply being accepted as
standard. Take English as example.

------
jokoon
finally.

Now, to make the gameplay programmer and level designer's job easier, you
still have to build well made and documented building blocks.

It's either that or hire people who do know how to talk a statically typed
language. Might be good news for the job market, I always found it weird to
have people making games who were not really competent in programming. always
baffled me.

I guess you can still force people who are unable to write good c++ to write
c++ anyways and hire somebody else to valgrind everything. In the end using a
statically typed language is more a requirement for performance, clarity and
consistency than a lack of flexibility.

Setting the bar high or demanding discipline if you prefer. Computers are
stupid, so you need to be precise when you work with them.

~~~
Guvante
Their blueprint system is phenomenally powerful without including any actual
code.

Heck it even allows live preview of how it is executing.

------
chris_wot
Looking at the comments around the post, the amount of people who don't really
understand pointers but who seem to be Unreal developers is a little
surprising!

~~~
mattnewport
But then, the number of people who don't really understand pointers but who
seem to be C/C++ developers is a little surprising...

------
Aardwolf
Can you script actors and such with C++ from within UnrealEd then?

~~~
pjmlp
As far as I understand, yes with the blueprints graphical system.

------
thomasahle
The idea:

> It is ... more dangerous than UnrealScript, C#, and JavaScript. But that is
> another way of saying that it's more powerful.

is why we can't have nice things.

------
hyp0
Am I cynical? The recent changes in Unreal 4 make me think the company is in
extremely serious trouble. It's because they aren't addressing the key reason
people buy a graphics engine ( _viz_ graphics), but all this ancilliary stuff.
While it is important, it's off center...

But maybe they are just trying to fend off Unity (open source, a more coherent
experience). Usually when companies do this, it's too late. I've no idea if
that's the case here.

~~~
k00pa
Haha.

Note how many games have come out using UE3, think about the royalties coming
in.

Also, right now they have just about the best game-engine, only hobbyists and
some indies would choose Unity, mostly because its easier.

UE4 will definitely get several high profile games soon from big AAA
companies.

I would say that Unity is in deep trouble right now :P

~~~
hyp0
note that disruption comes from below, not from big AAA titles...

~~~
untog
note that 90% of the profit comes from big AAA titles, not from below.

... I get what you're saying, but I think the Unreal Engine is going to
continue to be a cash cow for a good while yet.

~~~
hyp0
Digital had bumper profits just before they went under - it's typical, as they
go upmarket, to get greater profits. But I'll accept that you get what I'm
saying. :)

Another data point: id was killing it (and, to us, Carmack remains
undisputed). But they completely lost out the next generation, to Unreal,
because of vehicles. I don't think that'll happen here, just disclaimin' _past
performance is no guarantee of future success_.

Though, to be fair, the Quake engine underlied Call of Duty, the most
successful franchise (I believe), and it really showed in the framerate. Note:
no vehicles. And yes, past tense.

~~~
k00pa
They didn't even open the latest Id tech to public... They didn't even go to
the game.

It has nothing to do with vehicles.

~~~
hyp0
It was an example of losing dominance, not to do with open.

Re: vehicles. I'm going by what Carmack said in an interview.

~~~
k00pa
That sounds really weird, do you have a source for that interview?

~~~
hyp0
I agree it sounds weird!

He was talking aboout the time around Unreal Tournament 2004, and at that
generation, it was a big thing (kinda like waving grass was at one time).

Sorry, I don't recall which interview (and it would be hard to google unless
there's a transcript). It might have been one of his keynotes, perhaps the one
with Rage on an iPhone. I'm pretty sure it was a long one (at least 1.5
hours). It was one of the big popular videos on HN/r/programming (not an
esoteric one).

