Why C++ for Unreal 4

https://forums.unrealengine.com/showthread.php?2574-Why-C-for-Unreal-4&p=16252&viewfull=1#post16252

by zschoche • 12 years ago

209 171 12 years ago

forums.unrealengine.com

octo_t• 12 years ago

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.

squidi• 12 years ago

I love the irony of the contrast between this article and https://news.ycombinator.com/item?id=7584285. Not that either are wrong, but it demonstrates the constant flux of the software world.

jeremiep3• 12 years ago

There's a world of difference between a web server handling each requests within ~1-30 ms and a game simulating the entire world made from thousands of entities under ~16ms.

It is very possible to write games in high-level languages, but you will lose at least half the compute power of the machine by doing so. Note that unless you're writing a Gears of Wars, you don't really need such performance and productivity wins once again.

ksk• 12 years ago

Any specific examples? It would be interesting to go through the commit logs.

simias2• 12 years ago

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.

kibwen2• 12 years ago

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/

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

https://github.com/mozilla/rust/issues/2124

pjmlp10• 12 years ago

Another one is that all successful system programming languages have a OS vendor shipping them on their OS SDK.

That is the only way to make people adopt them. Otherwise they become just another language to do business applications.

kayoone• 12 years ago

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.

ajanuary2• 12 years ago

Unreal Engine 1 - 3 had a similar approach. The linked post describes why they no longer feel that approach is beneficial for them.

[Edit] Is Unity's approach drastically different in a way that solves them?

thefreeman2• 12 years ago

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

archagon2• 12 years ago

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/

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

archagon2• 12 years ago

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• 12 years ago

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

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

CmonDev4• 12 years ago

Can you make new Blueprint building blocks using Blueprint itself? Also it is still programming, just a visual kind of it.

k00pa5• 12 years ago

You can use the blueprints to create the game, you can also use the C++ to create the game.

You can also mix up the blueprints and C++.

At this point Unity only really has simplicity because of the lack of features, and well if people are too scared about C++.

Guvante3• 12 years ago

So why is Tim Sweeney saying that C++ is replacing UnrealScript for gameplay code?

Blueprints are a weird entity, not really code, but definitely similar.

I think the major difference is they are heavily event based and probably have severe performance restrictions placed on them, which is the major difference. If you want a real time-slice you need to do it in C++.

XorNot• 12 years ago

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.

xedarius• 12 years ago

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.

CmonDev4• 12 years ago

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.

scott_s2• 12 years ago

They would still need an interoperability layer, which was one of the main reasons for dropping UnrealScript.

kevingadd• 12 years ago

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

kcbanner• 12 years ago

I feel like .NET is a bad choice for this.

tinco• 12 years ago

The modmakers don't suffer too dearly, blueprint can do almost anything a modmaker could want, and in the future perhaps we can drop the almost.

They didn't really drop the highlevel language, they just dropped the idea of a highlevel general purpose language, favouring a strict DSL.

There's still a bit of interop, but you have to be very explicit about it. In C++ you use macro's to tell the compiler what's accessible to blueprint, and to access blueprint from C++ you have to make weird queries that are very obviously highly dynamic and ill-performant.

So cool stuff all around :)

RobotCaleb• 12 years ago

We ended up prototyping most things in UC then converting most of it to native code for performance reasons.

The reason builds were sometimes a bit tricky was due to chicken and egg syndrome because the script compilation wouldn't just compile scripts, but also modify headers to support the new objects created in script.

Aside from the performance issues, the main drawback (to me) with UC was definitely how tightly coupled to native code it was.

nly• 12 years ago

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

jeremiep3• 12 years ago

Time and State are first class constructs in UnrealScript, they are not in C++.

It's also possible to recompile UnrealScript files without recompiling the whole C++ program which took quite a while. (Unreal4 allows hot reloading C++ so this is no longer an issue.)

barrkel• 12 years ago

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.

snarfy• 12 years ago

There were a few constructs for dealing with scripts running on the client vs server and also data replication across the network built into the language. This is where it different from being just a scripting language.

Ultimately it was confusing at first. Besides the official docs I had to look at their script source and old UT2 tutorials to figure it out.

I haven't seen the new engine, but I imagine simply doing a net.replicate(&player_info) would have been more straight forward than dealing with all of the unrealscript language constructs for it.

danso• 12 years ago

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.

pjmlp10• 12 years ago

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• 12 years ago

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

dkersten3• 12 years ago

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

FTFY

On a serious note:

I've recently started using Clojure on the backend and ClojureScript on the frontend and while its not quite 100% of the way there, its close and quite pleasant to work with.

matthewmacleod• 12 years ago

Completely disagree. Server-side and client side are two completely different environments — different architecture, different security concerns, different user interfaces. Indeed, there's pretty much nothing shared.

Attempts to hide this have thus far all been leaky abstractions, and we're still in the research phase (e.g. Meteor). I'm not convinced that it will be possible to create a coherent web environment which abstracts the server-client boundary effectively.

Note that this doesn't preclude e.g. using Javascript as a server-side language. That's not related.

CmonDev4• 12 years ago

JavaScript only survived on client because we have to support legacy code across different platforms. There is no reason to pick same crappy language for server-side as well, unless you happen to be more familiar with it than modern languages.

m_mueller2• 12 years ago

There is at least one reason I can think of: Code sharing with mobile client implementations.

CyberShadow2• 12 years ago

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

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.

pjmlp10• 12 years ago

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.

leoc• 12 years ago

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

TillE• 12 years ago

That's fairly likely, and there are several of those projects underway in the forums. Unfortunately the engine is filled with weird macros and their own reimplementation of STL-like types, so any full binding is going to require quite a lot of wrapping.

I think the more effective solution for most developers will be to keep all the engine-adjacent code in C++, but integrate a scripting engine of your choice just with your game logic.

CyberShadow2• 12 years ago

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.

dkersten3• 12 years ago

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

CmonDev4• 12 years ago

"JS" - they want a better language, not worse one.

Aardwolf• 12 years ago

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

pjmlp10• 12 years ago

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

pjmlp10• 12 years ago

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• 12 years ago

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.

pjmlp10• 12 years ago

Note that Unreal uses a C++ GC.

Pxtl2• 12 years ago

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.

determinant• 12 years ago

It doesn't have to be an all or nothing proposition with C# or C++ anymore if Windows is your target environment. You can write the portions you want to write in C# and mix it in with C++/CLI. Yeah, I know, a lot of people think C++/CLI is ugly, but in the .NET world, it is a very clean glue language if you can get past the strangeness of having two different type systems (native and managed.)

You can essentially choose and manage how you want to deal with memory by virtue of how you choose between native and managed types, as well as control the behavior of the garbage collector itself.

pjmlp10• 12 years ago

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

http://www.viva64.com/en/b/0249/

golergka• 12 years ago

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.

thomasahle• 12 years ago

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.

beefsack• 12 years ago

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.

kibwen2• 12 years ago

There already exists a subcommunity devoted to exploring Rust's applicability to game development and computer graphics. The most active person in this department is probably Brendan Zabarauskas: http://voyager3.tumblr.com/post/82419271783/i-found-this-anc...

I also know of a few game development studios with R&D departments who have had an eye on Rust in the past, though I bet it will be a long time before a major studio is willing to make the risk that writing an engine in Rust would entail.

Narishma• 12 years ago

I don't think it will happen with Rust until it becomes more stable with no breaking changes between releases.

As for Go, it's not very well suited to this domain. Or at least no better suited than Java or C#.

bjz_12• 12 years ago

I don't think it will happen with Rust until it becomes more stable

Indeed. Most of the trail blazing work is being done by professional game devs in their spare time, hobbyists, indies and students who are willing to endure the pains of early adoption for the incredible gains that Rust gives them. It will only be post 1.0 however that the bigger players will be able to even consider using Rust. It's too risky to bet an entire company on – and that's coming from somebody who is willing to bet their indie project on it. ;)

mattgreenrocks2• 12 years ago

What's the appeal of Rust for gamedev?

gnuvince2• 12 years ago

A safer language with higher-level, low-cost abstractions.

bjz_12• 12 years ago

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

bjz_12• 12 years ago

I don't foresee big, established C++ code bases like the Unreal Engine being re-written from scratch, but once Rust reaches 1.0 it will definitely be a very compelling choice for new projects. It will start with the side-projects and indie projects, and gradually work its way up to larger and larger projects as the language proves itself. It's not a something that will happen overnight.

forrestthewoods3• 12 years ago

Can Rust code be compiled and debugged on PC, OS X, Linux, iOS, Android, PS4, and XB1? If the answer to any of those platforms is no then the answer to your question is no.

steveklabnik3• 12 years ago

iOS, PS4, and XB1 are missing.

I know it's not your point, just providing some answers in case someone is wondering.

lobster_johnson2• 12 years ago

I have high hopes for Nimrod [1] in that regard. Unlike Rust and Go, Nimrod is able to be almost as fast as C/C++ without sacrificing syntax; Nimrod's syntax often looks entirely like Python. For example, here's the example from the Nimrod home page:

    # compute average line length
    var count = 0
    var sum = 0

    for line in stdin.lines:
      count += 1
      sum += line.len

    echo "Average line length: ",
      if count > 0: sum / count else: 0

Type inference ensures that this uses efficient types internally, and is compiled to something very close to the efficiency of C. Here [2] is the generated C code, minus line tracing and stack trace frame generation. (Nimrod does things like bounds checking and overflow checking; without them, the program obviously becomes faster; the AddInt() function, for example, is replaced with a simple "+=".)

[1] http://nimrod-lang.org

[2] https://gist.github.com/atombender/f50e47c573f865d000ec

bjz_12• 12 years ago

Nimrod is a great language, but it has different goals to Rust. You get better expressiveness, and cleaner code, but you don't get the huge benefits of Rust's static type system. It depends on which you value more - I think there is a place for them both though.

anoplus• 12 years ago

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

chris_wot• 12 years ago

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• 12 years ago

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

HeXetic2• 12 years ago

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

hyp06• 12 years ago

I would guess the idea was to enable non-coders (esp. artists, level designers etc) to handle many of their needs themselves - for faster iteration.

But maybe the UnrealScript wasn't simple enough in practice to do that?

Or perhaps, giving people a template function, and a few functions, is just as easy/hard as a separate scripting language.

Generally, scripting languages are a really great idea: consider all the bash scripts in unix. An imperfect mismatch with the underlying language, yes; but worth it.

GeneralMayhem• 12 years ago

It sounds like the problem was that UnrealScript was initially too simple for the applications it was pushed to, which led to more and more of the underlying system being exposed through the interop API.

angersock3• 12 years ago

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.

HeXetic2• 12 years ago

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.

hyp06• 12 years ago

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.

k00pa5• 12 years ago

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

hyp06• 12 years ago

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

10098• 12 years ago

Last I checked Unity was a closed-source proprietary engine that I had to pay money for.

I'd say they should start worrying about Unity when something like Unreal Tournament 2004 (a decade old game btw) comes out built with Unity.

zanny3• 12 years ago

Maybe he means the Godot engine? I've heard a lot of newer kickstarters are eyeing it since it went FOSS.

daenz• 12 years ago

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• 12 years ago

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• 12 years ago

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

flohofwoe4• 12 years ago

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

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]

robrenaud• 12 years ago

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

It sounds like having a real software engineer do code reviews and/or rewrite the poor scripts before they get committed would be a solution to this problem. Presumably giving level designers the ability to script things is good for the game play.

greggman• 12 years ago

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

forrestthewoods3• 12 years ago

UE4 has hot reloading of C++ code. Some of their demos were pretty impressive. However I'd have to use it for a long period of time on a "real" project to see how reliable it truly is.

crucialfelix2• 12 years ago

The slightly obscure music programming language SuperCollider [1] added co-routines about 10 years ago and they became one of my beloved techniques. Was very glad to see them come to python and soon to mainstream javascript.

Boost has a c++ implementation but it looks quite different:

http://www.boost.org/doc/libs/1_55_0/libs/coroutine/doc/html...

[1] http://supercollider.github.io

edit: pythons new asyncio stuff looks very interesting:

https://docs.python.org/3.4/library/asyncio-task.html

VikingCoder3• 12 years ago

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.

bch• 12 years ago

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

I disagree that it has to follow that scripting -> bad code. I think of the C <--> scripting integration that I do as a Judo secret weapon. I get to easily fling "high-performance" C around in a super-dynamic way (REPL, easy-to-use high-level abstractions)... I think the problem you're describing is real (possibility to abuse/mis-use scripting power), but dismissing the notion of scripting plus C/C++ because of possibility of abuse seems like throwing out the baby with the bathwater. Better addressed with training and culture.

flohofwoe4• 12 years ago

Yes I actually agree, it's more of an organizational problem of who does what in a team. For fast prototyping, or working in a small team of experts it will be an advantage. There are only very few people which are gifted to be both a great artist and a pragmatic programmer who cares about code quality and performance. I think the right middle ground is that the programming team provides recombinable building blocks, which are low-level enough that combining them makes sense, but high-level enough that they are still easily controllable and maintainable. The UE4 blueprints sound like this.

midnightclubbed2• 12 years ago

By removing the power from your design team you are creating more work for the software engineers and removing tools from the creative team.

An ideal scripting language:

- Allows designers to build complex gameplay elements, define complex ai behaviors, create gameflow with minimal work from the software engineers.

- Handles memory allocation/destruction behind the scenes

- Does not crash the game when an error occurs

- Handles multithreading and/or events

- Does not allow designers to shoot themselves in the foot

- Has a simple and clean syntax

- Allows software engineers to expose their APIs to it easily

- Can be reloaded on the fly

If you control the feature set of the scripting language then it becomes a crucial tool for rapid development of your game - empowering the creative team to make their game and allowing the software engineers to concentrate on all the other stuff that needs their attention.

In my opinion visual scripting and component systems can be a useful addition to an engine, but I have always seen a usefulness in having a scripting language layer.

(I have shipped multiple high profile console games with more lines of script code than of game code and design teams matching the size of the programming teams)

flohofwoe4• 12 years ago

Did you use an existing scripting language, or roll your own? How did you handle debugging and profiling, and did you limit access to control constructs like loops, variables, etc..? Did the scripting system have some sort of per-frame budget/quota? Curiously interested...

mccr8• 12 years ago

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/

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

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

jokoon• 12 years ago

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.

Guvante3• 12 years ago

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

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

syncsynchalt• 12 years ago

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

Seems an appropriate term here.

Guthur2• 12 years ago

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.

Why C++ for Unreal 4

Related Stories