9 ms·

Why C++ for Unreal 4

209 points by zschoche 12y ago

octo_t 12y 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 12y ago
  I love the irony of the contrast between this article and https://news.ycombinator.com/item?id=7584285 https://news.ycombinator.com/item?id=7584285. Not that either are wrong, but it demonstrates the constant flux of the software world.
  - jeremiep 12y 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.
    - Guthur 12y ago
      "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." Sounds definitive, interesting considering that in some cases languages like OCaml outperform C++. C++ does not mystically provide good performance. Knowledge of algorithms and appropriate data structures are far more beneficial. Does the coder know how to come up with something like http://en.wikipedia.org/wiki/Fast_inverse_square_root http://en.wikipedia.org/wiki/Fast_inverse_square_root or the cost of a hash map verses indexed array lookup. These will win you far more than any language choice.
      - jeremiep 12y ago
        I completely agree about knowledge of algorithms and data structures being far more important to programming than the choice of language. Many languages can outperform C++ in some cases and this language it would not be my choice for a next-gen game engine either (D would be). The thing about going native, however, is that you also control the memory layout of these data structures easily to lower cache miss rates. You can write highly performant code in all the cases where its needed. For a game engine that's very likely to be most of the sub-systems updating the game objects and interfacing with the hardware. Writing native code makes it pretty straightforward once you learn to structure your data for cache locality and prefetch the memory when you know its going to be needed. Video game engines are chock-full of use-cases for this. I'm mostly a functional programmer now and I do love referential transparency. It's perfect to reason about the logic of our programs and has completely changed how I view software now. But the tradeoff for this is that we lose the ability to easily reason about the execution speed of our programs without deep knowledge on how it gets compiled, and is usually dependent on the compiler vendor. For real-time applications crunching tens of thousands of objects 60 times a second running sometimes on sub-par hardware written by armies of programmers straight out of Java-School, this makes C++ a no-brainer.
- ksk 12y ago
  Any specific examples? It would be interesting to go through the commit logs.
- simias 12y 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.
  - kibwen 12y 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/ 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 12y ago
      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
  - pjmlp 12y 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.
deleted 12y ago
[deleted]
kayoone 12y 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.
- ajanuary 12y 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?
  - deleted 12y ago
    [deleted]
- thefreeman 12y 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-for-Unreal-4&p=16730&viewfull=1#post16730 https://forums.unrealengine.com/showthread.php?2574-Why-C-fo...
archagon 12y 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 12y ago
  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
- CmonDev 12y ago
  Can you make new Blueprint building blocks using Blueprint itself? Also it is still programming, just a visual kind of it.
- k00pa 12y 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++.
- Guvante 12y 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 12y 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 12y 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.
- CmonDev 12y 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_s 12y ago
    They would still need an interoperability layer, which was one of the main reasons for dropping UnrealScript.
  - kevingadd 12y 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).
    - azakai 12y ago
      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.
nly 12y 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
- janna_gray 12y ago
  You're so unreal.If you don't stop I might give you. give you. you know. pleasure.and you will like it,
- jeremiep 12y 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 12y 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 12y 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 12y 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.
- pjmlp 12y 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 12y ago
    I've yet to meet a designer that can do the above. Its very much a black magic regardless of who you are.
- dkersten 12y 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 12y 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.
- 12y ago
CyberShadow 12y 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 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 12y 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 12y ago
The upshot is likely that a community-created Lua or JS binding will gain a significant userbase.
- TillE 12y 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.
- CyberShadow 12y 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.
  - dkersten 12y ago
    The LuaJIT interpreter is surprisingly fast. Still not as fast as the JIT or an AOT compiled language though...
    - NickPollard 12y ago
      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.
      - myrmidon 12y ago
        LuaJIT contains a pretty fast interpreter, thus it makes sense to use it on consoles (with the JIT turned off by compile-time-flags) instead of the Lua reference implementation.
      - 12y ago
Aardwolf 12y ago
Can you script actors and such with C++ from within UnrealEd then?
- pjmlp 12y ago
  As far as I understand, yes with the blueprints graphical system.
pjmlp 12y 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 12y 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.
  - pjmlp 12y ago
    Note that Unreal uses a C++ GC.
    - m_mueller 12y ago
      I'm neither an Unreal nor a C++ expert, but I assume that this kind of GC still allows exact control over when the collection happens since it's not language- but a library feature. In this case this should still be better for game engine purposes, since the GC can for example be hidden behind GPU rendering time.
      - pjmlp 12y ago
        C++ has a GC API since C++11. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2670.htm http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n267... Currently Visual C++ is the only C++ compiler offering support for it. As for Unreal, I only know it has one by reading game development foruns. I don't know what type of control it offers.
    - k00pa 12y ago
pjmlp 12y ago
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/
golergka 12y 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 12y 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 12y 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.
- kibwen 12y 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-ancient-work-in-my-old-deviant-art 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 12y 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_ 12y 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. ;)
- mattgreenrocks 12y ago
  What's the appeal of Rust for gamedev?
anoplus 12y ago
A(programming) language gets very powerful by simply being accepted as standard. Take English as example.
chris_wot 12y 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 12y 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...
HeXetic 12y 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".
- hyp0 12y 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 12y 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.
- angersock 12y 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.
hyp0 12y 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.
- k00pa 12y 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
  - hyp0 12y ago
    note that disruption comes from below, not from big AAA titles...
    - untog 12y ago
      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 12y ago
        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.
daenz 12y 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 12y 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 12y 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...
flohofwoe 12y 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 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 12y 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.
- 12y ago
mccr8 12y 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/ 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
jokoon 12y 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.
- Guvante 12y ago
  Their blueprint system is phenomenally powerful without including any actual code. Heck it even allows live preview of how it is executing.
syncsynchalt 12y 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 http://en.wikipedia.org/wiki/Inner_platform Seems an appropriate term here.
Guthur 12y 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.

209 points by zschoche 12y 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 12y ago
I love the irony of the contrast between this article and https://news.ycombinator.com/item?id=7584285 https://news.ycombinator.com/item?id=7584285. Not that either are wrong, but it demonstrates the constant flux of the software world.
- jeremiep 12y 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.
  - Guthur 12y ago
    "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." Sounds definitive, interesting considering that in some cases languages like OCaml outperform C++. C++ does not mystically provide good performance. Knowledge of algorithms and appropriate data structures are far more beneficial. Does the coder know how to come up with something like http://en.wikipedia.org/wiki/Fast_inverse_square_root http://en.wikipedia.org/wiki/Fast_inverse_square_root or the cost of a hash map verses indexed array lookup. These will win you far more than any language choice.
    - jeremiep 12y ago
      I completely agree about knowledge of algorithms and data structures being far more important to programming than the choice of language. Many languages can outperform C++ in some cases and this language it would not be my choice for a next-gen game engine either (D would be). The thing about going native, however, is that you also control the memory layout of these data structures easily to lower cache miss rates. You can write highly performant code in all the cases where its needed. For a game engine that's very likely to be most of the sub-systems updating the game objects and interfacing with the hardware. Writing native code makes it pretty straightforward once you learn to structure your data for cache locality and prefetch the memory when you know its going to be needed. Video game engines are chock-full of use-cases for this. I'm mostly a functional programmer now and I do love referential transparency. It's perfect to reason about the logic of our programs and has completely changed how I view software now. But the tradeoff for this is that we lose the ability to easily reason about the execution speed of our programs without deep knowledge on how it gets compiled, and is usually dependent on the compiler vendor. For real-time applications crunching tens of thousands of objects 60 times a second running sometimes on sub-par hardware written by armies of programmers straight out of Java-School, this makes C++ a no-brainer.
ksk 12y ago
Any specific examples? It would be interesting to go through the commit logs.
simias 12y 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.
- kibwen 12y 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/ 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 12y ago
    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
- pjmlp 12y 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.

deleted 12y ago

[deleted]

kayoone 12y 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.

ajanuary 12y 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?
- deleted 12y ago
  [deleted]
thefreeman 12y 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-for-Unreal-4&p=16730&viewfull=1#post16730 https://forums.unrealengine.com/showthread.php?2574-Why-C-fo...

archagon 12y 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 12y ago
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
CmonDev 12y ago
Can you make new Blueprint building blocks using Blueprint itself? Also it is still programming, just a visual kind of it.
k00pa 12y 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++.
Guvante 12y 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 12y 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 12y 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.

CmonDev 12y 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_s 12y ago
  They would still need an interoperability layer, which was one of the main reasons for dropping UnrealScript.
- kevingadd 12y 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).
  - azakai 12y ago
    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.

nly 12y 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

janna_gray 12y ago
You're so unreal.If you don't stop I might give you. give you. you know. pleasure.and you will like it,
jeremiep 12y 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 12y 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 12y 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 12y 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.

pjmlp 12y 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 12y ago
  I've yet to meet a designer that can do the above. Its very much a black magic regardless of who you are.
dkersten 12y 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 12y 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.
12y ago

CyberShadow 12y 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 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 12y 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 12y ago

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

TillE 12y 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.
CyberShadow 12y 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.
- dkersten 12y ago
  The LuaJIT interpreter is surprisingly fast. Still not as fast as the JIT or an AOT compiled language though...
  - NickPollard 12y ago
    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.
    - myrmidon 12y ago
      LuaJIT contains a pretty fast interpreter, thus it makes sense to use it on consoles (with the JIT turned off by compile-time-flags) instead of the Lua reference implementation.
    - 12y ago

Aardwolf 12y ago

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

pjmlp 12y ago
As far as I understand, yes with the blueprints graphical system.

pjmlp 12y 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 12y 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.
- pjmlp 12y ago
  Note that Unreal uses a C++ GC.
  - m_mueller 12y ago
    I'm neither an Unreal nor a C++ expert, but I assume that this kind of GC still allows exact control over when the collection happens since it's not language- but a library feature. In this case this should still be better for game engine purposes, since the GC can for example be hidden behind GPU rendering time.
    - pjmlp 12y ago
      C++ has a GC API since C++11. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2670.htm http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n267... Currently Visual C++ is the only C++ compiler offering support for it. As for Unreal, I only know it has one by reading game development foruns. I don't know what type of control it offers.
  - k00pa 12y ago

pjmlp 12y ago

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/

golergka 12y 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 12y 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 12y 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.

kibwen 12y 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-ancient-work-in-my-old-deviant-art 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 12y 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_ 12y 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. ;)
mattgreenrocks 12y ago
What's the appeal of Rust for gamedev?

anoplus 12y ago

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

chris_wot 12y 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 12y 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...

HeXetic 12y 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".

hyp0 12y 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 12y 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.
angersock 12y 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.

hyp0 12y 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.

k00pa 12y 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
- hyp0 12y ago
  note that disruption comes from below, not from big AAA titles...
  - untog 12y ago
    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 12y ago
      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.

daenz 12y 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 12y 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 12y 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...

flohofwoe 12y 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 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 12y 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.
12y ago

mccr8 12y 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/ 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

jokoon 12y 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.

Guvante 12y ago
Their blueprint system is phenomenally powerful without including any actual code. Heck it even allows live preview of how it is executing.

syncsynchalt 12y 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 http://en.wikipedia.org/wiki/Inner_platform Seems an appropriate term here.

Guthur 12y 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.